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Manual Objectives 

The objective of this manual is to provide (1) a complete description of the 
BLISS programming language and (2) tutorial information on its use. This 
manual documents the three dialects of the language: BLISS-16, BLISS-32, 
and BLISS-36. It is intended as a self- teaching manual for experienced high- 
level language users, and as a reference tool. It does not describe the BLISS 
compilers (except in overview fashion) or their operation; this is done in 
separate User's Guides. 

Intended Audience 

This manual is primarily intended for system programmers, including those 
whose programming tasks would traditionally imply the use of assembly lan- 
guage. It is also addressed to other programmers for whom the transportabil- 
ity of programs between several BLISS target systems is of prime concern. 
Familiarity with the basic architecture of one or more of the target systems is 
assumed; familiarity with the relevant assembly language is not assumed, 
however. The BLISS target systems are the VAX-11, PDP-11, DECsys- 
tem-10, and DECSYSTEM-20. 

Structure of this Document 

The manual begins with three chapters that lay the foundation for the defini- 
tion of BLISS. Chapter 1 discusses the BLISS dialects, introduces fundamen- 
tal concepts, and illustrates the main features of the language. (It is an essen- 
tial part of the manual.) Chapter 2 discusses the organization of the language 
definition and describes the syntax notation used in this manual. Chapter 3 is 
an introduction to the data and program structure of BLISS. 

The next seventeen chapters of the manual, Chapters 4 through 20, provide a 
complete description of the language. This description includes not only the 
rules for interpreting BLISS programs, but also examples, explanations, and 
programming guidelines. 



The manual has four appendices. Appendix A is a list of the identifiers that 
have predefined meanings in BLISS. Appendix B defines the several string 
encodings available in BLISS. Appendix C describes the transportability 
checking that is optionally provided by the BLISS compilers. Appendix D is a 
list of the builtin machine-specific- functions associated with each BLISS dia- 
lect. 

Associated Documentation 

The following documents relate specifically to BLISS and the use of its 
compilers: 

• BLISS Pocket Guide 

A syntax and command summary for all dialects and host systems 

• BLISS-16 User's Guide 

For BLISS-16 compiler usage on the VAX-11, DECsystem-10, or DEC- 

SYSTEM-20 

Target system — PDP-11 

• BLISS-32 User's Guide 

For BLISS-32 compiler usage on the VAX-11 
Target system — VAX-11 

• BLISS-36 User's Guide 

For BLISS-36 compiler usage on the DECsystem-10 or DECSYSTEM-20 
Target system — DECsystem-10 or DECSYSTEM-20 

Each User's Guide provides machine-specific programming information as 
well as basic information about linking and executing BLISS programs on the 
target system. 

For VAX-11 users: The following documents provide additional information 
relating to the linking, execution, and debugging of BLISS-32 programs under 
the VAX/VMS operating system: 

• VAX-11 Linker Reference Manual 

• VAX/ VMS Command Language User's Guide 

• VAX-11 Symbolic Debugger Reference Manual 

The VAX-11 Information Directory lists and describes all other documents 
that you may need to refer to in the course of building and executing a 
BLISS-32 program. 
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Chapter 1 
Introduction 



BLISS is a system implementation language for three DIGITAL computer 
families: 

• The 16-bit PDP-11 line, 

• The 32-bit VAX-11 line, and 

• The 36-bit DECsystem-10 and DECSYSTEM-20 lines. 

Because of the dissimilarities among these target systems, BLISS has three 
dialects: BLISS-16, BLISS-32, and BLISS-36. The numeric suffix indicates 
the word length, in bits, of the respective target system. 

BLISS is classified as a system implementation language — rather than an 
application-oriented language — because BLISS is primarily intended for 
building system software, such as operating systems, compilers, utilities, and 
real-time processors. Such software is often large and complicated, is often 
close to the hardware, and is usually very sensitive to efficiency. In addition, 
most system software is very frequently used by many individuals (in some 
cases with an unpredictable variety of input data), and therefore must be 
highly dependable. 



1.1 BLISS Dialects 



Each BLISS dialect is supported by a separate compiler. The BLISS-16 com- 
piler is a cross-compiler, that is, it executes on a VAX-11, a DECsystem-10, 
or a DECSYSTEM-20 but compiles code for its target system, the PDP-11. 
The BLISS-32 and BLISS-36 compilers are native: they execute on their own 
target system. Each BLISS compiler is described in a BLISS User's Guide for 
that dialect. 

BLISS-16, BLISS-32, and BLISS-36 are dialects of a single language. Each 
dialect consists of a body of identical language features called Common 
BLISS (which forms the bulk of each dialect), plus a number of features 
either unique to one dialect or shared by only two of the three. Common 
BLISS constitutes the transportable language base. 
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The dialect-specific features reflect architectural characteristics of one target 
system that are not found in each of the others, for instance byte-addressing 
capability, found in the 16- and 32-bit target systems but not in the 36-bit 
systems. While it is possible to implement most programs in Common BLISS 
only, without reference to system-specific functions or characteristics, it is not 
always desirable to do so. This point is discussed further under the topic of 
transportability. 

1.2 Language Objectives and Characteristics 

1.2.1 Design Objectives 

Because of the system-software orientation of BLISS, a number of its primary 
objectives differ from those of application-oriented languages such as 
COBOL, FORTRAN, and PL/I. Foremost among those objectives are: 

1. Highly optimizable object code. 

2. Simple and consistent facilities for operating on addresses. 

3. Control constructs which encourage well structured source code, in the 
interests of program reliability, clarity, and maintainability. 

4. Facilities for defining both the representation of a user-designed data 
structure and the manner of accessing the data in that structure. 

5. Optional access to specific features of the target-system hardware or 
operating system. 

6. Facilities for defining, at an appropriately high level, the linkage con- 
ventions used in calling routines or procedures. 

Because the language supports three different computer systems, an addi- 
tional objective is program transportability across the target systems. BLISS, 
therefore, includes many features specifically designed to facilitate trans- 
portable programming. These features are discussed later in this chapter 
(Section 1.5). 

1.2.2 Language Overview 

BLISS has many of the features of other modern high-level languages. It has 
block structure, an automatic stack, and mechanisms for defining and calling 
(recursive) routines. It uses algebraic notation for calculations and has opera- 
tions for arithmetic, shifting, comparison, and logic. It provides a variety of 
predefined data structures and permits the programmer to define additional 
data structures. It has facilities for testing and iteration that support clear 
and reliable programming. (These same facilities also allow the compiler to 
perform extensive flow optimizations.) 

On the other hand, BLISS omits certain features of other high-level lan- 
guages. It does not have built-in facilities for input/output, because a system- 
software project usually develops its own input/output or builds upon basic 
monitor I/O services. It avoids certain kinds of automation of the program - 
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ming process which introduce inefficiency for the sake of convenience. It is 
machine dependent to the extent that it permits access to machine-specific 
features, since system software often requires this. 

BLISS has characteristics that are unusual among high level languages. A 
name representing a data segment (that is, a storage location) is uniformly 
interpreted as the address of that segment rather than the value of the seg- 
ment, and the language includes an explicit fetch operator that denotes "con- 
tents of". 

Also, BLISS is an 'expression language' rather than a 'statement language'. 
This means that every construct of the language that is not a declaration is an 
expression. Expressions produce a value as well as possibly causing an action 
such as modification of storage, transfer of control, or execution of a program 
loop. For example, the counterpart of an assignment "statement" in BLISS is, 
strictly speaking, an expression that itself has a value. The value of an expres- 
sion can either be used or discarded in BLISS. When the value of an expres- 
sion is discarded, the expression is said to be used in a "statement like" way, 
i.e., used solely for the action or side-effect that it produces. (See Section 1.4.5 
for further discussion.) 

Finally, BLISS includes a macro facility that provides a level of capability 
usually found only in macro-assemblers. 

The remainder of this introduction provides a first look at some specifics of 
the language. The several steps involved in the development of a BLISS 
program are outlined, the main features of BLISS are described, the compo- 
nents of the BLISS software system are discussed, and finally a simple but 
complete BLISS program is given. 



1.3 Program Development 



The typical development of a BLISS program, from inception to successful 
execution, is outlined below in order to introduce certain concepts and terms 
used later in this manual: 

1. Design. To provide a logical structure for the program, it is organized 
into a set of routines and associated data structures. In general, each 
routine corresponds to a clearly identified, relatively independent func- 
tion or subfunction of the program. One of the routines is the main 
routine. Later, when the program is executed, this routine is called by 
the operating system. The main routine controls the overall flow of the 
program, calling other routines which may in turn call yet other 
routines, and so on, until every routine has done its assigned job. 

2. Programming. Once the routines and data structures have been de- 
signed, they are programmed in the BLISS language. The routines are 
grouped into modules for the purposes of compilation. The routines 
grouped into a given module might, for example, consist of those pro- 
grammed by one member of a project team. They might also reflect a 
logical grouping that aids overall system understanding and facilitates 
structured testing. Each module is a text file that is called a BLISS 
source file. 
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3. Compilation. Once the modules have been programmed, each module 
is compiled. Each module can be compiled individually, and this is one 
practical advantage of dividing a large program into several modules. 
The result of each compilation is an object file. An object file is a 
sequence of encoded machine instructions and linker directives that is 
equivalent to the corresponding source module. 

4. Linking. When all the modules of a program have been compiled, 
they are linked. The linker effectively "binds together" the various 
object modules, supplies any routines requested from a common-routine 
library, and converts the compiler-encoded relative addresses to actual 
machine addresses. (Section 1.7.1 gives further details.) The result of 
linking is a single file that contains the executable program image. 

5. Execution. The program image is executed. The first executions are 
normally done with the assistance of a debugging package. As bugs are 
found, the development process cycles back to compilation, program- 
ming, or, most unfortunately, to design. Eventually, the program is 
ready for useful execution. 

This manual provides the information necessary for the second step in the 
development process, programming. The BLISS user's guides (one for each 
dialect) provide complete information about the third step, compilation, plus 
guidelines for linking, executing, and debugging. 

The user's guides also contain detailed information about certain dialect- 
specific features, such as machine-specific functions and module switches 
that describe the target-system environment, and about transportable pro- 
gramming. 

1.4 The Main Features of BLISS 

This section contains a brief description of BLISS. Those aspects of BLISS 
that are different from other high level programming languages are empha- 
sized. The description is informal and omits many details; its purpose is to 
provide the reader with an intuitive understanding of BLISS that will be 
useful in further study of the language. 

1.4.1 Data 

All BLISS calculations are performed on values that correspond, in size, to 
the largest efficiently-accessible unit of memory in each target system. This 
value, called a BLISS fullword, is 16 bits long for BLISS-16 (PDP-11 word), 
32 bits long for BLISS-32 (VAX- 11 longword), and 36 bits long for BLISS-36 
(DECSYSTEM-10/20 word). A fullword can be viewed as a sequence of sin- 
gle-bit logical values (true or false), as a sequence of ASCII character codes, or 
as a unitary value. As a unitary value, it can be interpreted as a signed 
integer, an unsigned integer, or a memory address. 

In many high level languages, a specific interpretation or "type" is perma- 
nently associated with each program variable. For example, one variable 
might be declared as containing an address value while another contains an 
unsigned integer. In BLISS, however, an interpretation is not associated with 
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a variable. Instead, the interpretation of the value is specified by the operator 
that is applied to it. For example, BLISS has three operators for equality: 
EQL, EQLU, and EQLA. These operators interpret their operands as signed 
integers, unsigned integers, and memory addresses, respectively. 

In order to conserve storage, data is often stored in fields, which are units of 
data that are less than a fullword in length. One field of special importance in 
all three dialects is the bit, which can be used to store a single logical value. In 
both BLISS-16 and BLISS-32, the 8-bit byte can be efficiently accessed and 
manipulated, and used for instance to store an ASCII character. In BLISS-32, 
the 16-bit word (which is the fullword of BLISS-16) can also be manipulated 
efficiently by the target hardware. No matter what field size is involved, 
however, a field value is always extended to a fullword value whenever it is 
fetched from memory. 

1.4.2 Memory Addressing 

Although calculations are always performed on fullwords, memory is ad- 
dressed in fullword units only in the case of BLISS-36, where the target 
system's addressable unit is the full machine word. In both BLISS-16 and 
BLISS-32, the basic addressable unit is the byte. That is to say, if a memory 
address is incremented by 1 in either of these dialects, the location pointed to 
by the resulting address value is the next byte, not the next fullword. 

Therefore, in order to precisely describe the interpretation of an address ex- 
pression such as X+8 in a dialect-specific fashion, several different formula- 
tions would be required for the same expression. For example, assuming a 
fullword-reference context, the interpretation of the expression X+8 for 
BLISS-16 or BLISS-32 would be: "Locate the fullword of memory that begins 
eight bytes after the byte whose address is X"; whereas the interpretation for 
BLISS-36 would be: "Locate the fullword of memory that is eight fullwords 
after the fullword whose address is X". 

In the interest of both generality and brevity, the non-specific term "address- 
able unit" is used instead of "byte" or "fullword" in such descriptions, so that 
the two formulations given above reduce to the equivalent one: "Locate the 
fullword that begins eight addressable units after the unit whose address 

is X". 

1.4.3 Fetching Values 

In many programming languages, the interpretation of the name of a storage 
location depends on its context. Consider FORTRAN, for example. If the 
name appears as the left-hand side of an assignment, it represents the address 
of the storage location. If the name appears within an expression, it represents 
the contents of the storage location. 

In BLISS, however, the interpretation of the name of a storage location does 
not depend on the context. Instead, the name always represents the address of 
the storage location. For example, 

X + 3 

is evaluated by adding 3 to the address that is associated with X. 
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When the content of a storage location is needed, the fetch operator, ".", is 
used. For example: 

.X + 3 

This expression is evaluated by adding 3 to the content of storage-unit X. 
More exactly, the value of the expression is obtained as follows: Locate and 
fetch the fullword of memory that begins with the addressable unit whose 
address is X, and add 3 to the fetched value. 

The fetch operator is an unusual feature of BLISS; it is not present in such 
languages as ALGOL, COBOL, FORTRAN, and PL/I. The omission of a fetch 
operator here and there is a frequent error among most beginning BLISS 
programmers. On the other hand, because BLISS always interprets a name as 
an address, it is easy to treat addresses as data, and address arithmetic can be 
performed in a simple and consistent way. 

1.4.4 Assigning Values 

A value is assigned to storage by an assignment operator, "=". An example of 
an assignment is: 



This assignment means "form a fullword value that represents 2, and then 
store that value in the fullword of memory whose address is X." 

In BLISS, an assignment can be viewed as just another expression. Its first 
operand (left-hand-side) provides a value that is interpreted as the address of 
a data segment. Its second operand (right-hand-side) provides a value that is 
stored at the given address. The assignment expression itself has a value, 
namely the value of its second operand; more is said of this in the next 
section. 

Often the left-hand-side of an assignment is just a name. However, in BLISS 
there is no restriction on the expression that appears on the left-hand-side of 
an assignment. Whatever that expression is, it is evaluated and the resulting 
value is interpreted as an address. For example, 

X + G = 2 

assigns 2 to the fullword of memory that begins six addressable units after the 
unit whose address is X. The example just presented is valid and illustrates 
an important feature of BLISS. However, such an assignment would not 
appear in a well-designed program, and especially not in a transportable one. 
Instead, an address computation, such as X+6 in the example, would be 
performed through a structure-reference (see Chapter 11). 

1.4.5 Expressions 

Many high level programming languages classify each construct of the lan- 
guage either as a statement, which performs an action without producing a 
value, or as an expression, which calculates a value. For example, such lan- 
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guages classify the assignment construct as a statement, and do not permit its 
use in a context requiring a value. 

In BLISS, any construct except a declaration can be used as an expression. 
For constructs that are statement-like, BLISS defines a value. For example, 
the value of an assignment is the value of the right-hand side of the assign- 
ment. The expression 

2*(B = ,C + 1 ) 

contains an assignment. When the expression is evaluated, it calculates 
2*(.C+1). At the same time, without performing any additional calculation, it 
stores the value of .C+l in location B. 

The absence of statements from BLISS does not require a new approach to 
programming. Whenever a construct is used in a statement-like way, it is 
terminated by a semicolon and its value is discarded. The expression 

o = 2*,r; 

is a terminated expression. It assigns the value of 2*.R to Q and then, having 
no further use for the value, discards it. Such constructs as this, ending with a 
semicolon, play the role of statements in BLISS. 

1.4.6 Blocks 

A block is a syntactic feature of BLISS that is used to gather together a 
portion of a program and make it into a single unit (in fact, into a form of 
expression). In its most familiar form, a block is the keyword BEGIN followed 
by a sequence of declarations followed by a sequence of terminated expres- 
sions followed by the keyword END. An example is: 

BEGIN 
LOCAL TEMP! 

TEMP = .)•<; 

X = ,Y! 

Y = .TEMP! 

END 

This block contains one declaration and three terminated expressions. The 
declaration specifies that TEMP designates a storage location that will be 
used only during execution of the block. Each of the three terminated expres- 
sions is an assignment and, together, they exchange the contents of X and Y. 
The entire block is, itself, a primary expression. Sometimes it is useful to 
provide a value for a block. In that case, an expression without the terminal 
semicolon is placed at the end of the block. An example is: 

Z = BEGIN 

LOCAL temp; 
TEMP = ♦>•<; 
x = , y ; 
y = .temp; 

.X EQL . y 
END 

This block exchanges the contents of X and Y just as the previous example of 
a block did. In addition, the contents of X and Y are compared and the value 
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of the block is 1 or 0, depending on whether or not the values are equal. When 
execution of the block is complete, its value is assigned to Z. 

In the first example, if the semicolon following the final expression 
(Y = .TEMP) were omitted, the block would have as its value the contents of 
location TEMP, according to the evaluation rule given for assignments in 
Section 1.2.4. (Chapter 8 gives a full description of the semantics and use of 
the semicolon in the context of expressions and blocks.) 

A block that does not contain declarations is called a compound expression. 
An example that uses such a block is: 

IF .A NEQ 
THEN 

BEGIN 

B = . P + . A 5 

c = .o + ♦ a ; 

END 

In this example, the compound expression gathers two separate assignments 
into a single construct. Both assignments are performed if the content of A is 
not and both are skipped otherwise. 

In BLISS, a parenthesis pair and a BEGIN-END pair can be used inter- 
changeably. For example, the preceding example can be written equivalently 
as: 



IF , A 


NEQ 




THEN 






B 


= .P + 


.a; 


C 
) 


= ,Q + 


f a ; 



or, more compactly, as: 

IF .A NEQ THEN (B=.P+.A5C= ,0 + ,Ai) 

A block that uses a parenthesis pair and contains just one expression is a 
parenthesized expression; it is the ultimate specialization of a block. An ex- 
ample of the use of some parenthesized expressions is: 

. (A + 1 )*(B - 1 ) 

Because the parentheses are present, the addition is performed before the 
fetch operation, and the multiplication is performed last of all, When the 
parentheses are removed, the expression is: 

♦A + 1*B - 1 

This expression has a different meaning because the operators refer to differ- 
ent operands. According to the priority rules given in Chapter 5, the fetch 
operation is performed before the addition, and the multiplication is per- 
formed before the addition or subtraction. Thus parenthesized expressions are 
used to override the priority rules. 
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1.4.7 Declarations 

Every name in a BLISS program must be declared. The purpose of the decla- 
ration is to provide the BLISS compiler with information about the name. A 
simple example of a declaration is: 

OWN 

x; 

This declaration says that X designates a storage location that is permanently 
allocated (in the OWN program section) before program execution begins. 
(Note that, in the context of declarations, the semicolon is simply a manda- 
tory terminator.) 

A more complicated example of a declaration is: 

OWN 

ALPHA: VECTOR CI 00] INITIAL (REP 100 OF (0))i 

This declaration not only specifies that ALPHA is an OWN name, but also 
gives two attributes, which begin with the keywords VECTOR and INITIAL. 
The VECTOR attribute describes the structure of the storage designated by 
ALPHA. The INITIAL attribute provides initial values for the storage. 

The preceding examples are declarations of names of data addresses. An 
example of the declaration of a name of a routine address is: 

ROUTINE EXCHANGE ( A tB) s N00ALUE = 
BEGIN 
LOCAL 

temp; 

TEMP = ,,Ai 
♦A = . ,B 5 
♦B = *TEMP5 

end; 

This routine exchanges the contents of the two locations that are given 
through the formal names, A and B. The extra fetch operator used with these 
formal names reflects the fact that a formal name is the address of a storage 
location that contains a parameter; it is not the parameter itself. 

The attribute NOVALUE indicates that this routine does not return a value, 
since the last expression within the routine body is a terminated expression. 
Therefore, a call on this routine must appear in a context that does not require 
a value. For example, the call could be used in a statement-like way. The 
semicolon following the keyword END is simply the required declaration ter- 
minator, and as such has nothing to do with whether or not the routine returns 
a value. 

Some names do not represent addresses. For example, 

MACRO 

= » 3 % 5 

declares the name of a macro, Q. During compilation, every occurrence of Q in 
the scope of this declaration is replaced by the text "0,3". 
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Declarations are scoped by the block structure of a program. The same name 
can be used in different blocks for different purposes. Thus it is not necessary 
to use an awkward name because the appropriate name has been used in some 
other part of the same program. 

1.4.8 Structures 

The most commonly used forms of data structures are defined as part of 
BLISS. An example of a use of such a structure was given in the preceding 
discussion of declarations; it is: 

OWN 

ALPHA; VECTOR C100] INITIAL (REP 100 OF (0))! 

In this declaration, VECTOR[100] is the structure-attribute. It specifies that 
ALPHA designates a data-segment in storage that is not a single fullword, but 
rather is a sequence of 100 full words. The first of the full words is referenced by 
ALPHA[0], the second by ALPHA[1], and so on up to ALPHA[99]. An example 
of a reference to this vector is: 

ALPHAC.I-13 = 5 

Suppose that, for a given execution of this assignment, the content of I is 8. 
Then the assignment is equivalent to 

ALPHA[7] = 5 

and its effect is to set the eighth element of the vector to 5. 

In addition to VECTOR, three other kinds of data structures (BITVECTOR, 
BLOCK, BLOCKVECTOR) are defined as part of BLISS. Beyond that, how- 
ever, is the capacity of BLISS to accept programmed definitions of data 
structures. This feature permits the programmer to define data structures 
that are designed precisely for a given application. A part of the data-struc- 
ture definition is the 'algorithm' for accessing the structure. For example, a 
structure can be programmed to pack data in a way that saves storage or to 
include special checks for illegal accesses. 

1.4.9 Flow of Control 

Alternative actions to be taken by a program can be controlled by a condi- 
tional-expression. An example is: 

IF . X GTR 
THEN 

Y = . X 
ELSE 

Y = - • X i 

This example sets Y to the absolute value of the contents of X. It ends with a 
semicolon, and is therefore a statement-like use of a conditional-expression. 
Another example is: 

Y = (IF .X GTR THEN .X ELSE -,X>5 

This example also sets Y to the absolute value of the contents of X. However, 
in this example the value of the conditional-expression is used. Its value is .X 
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or -.X, depending on whether or not the test is satisfied. Once the value of the 
conditional-expression is calculated, it is assigned to Y. 

A more specialized construct for alternative flow of control is the case-expres- 
sion. An example is: 

CASE ♦>< FROM 1 TO 8 OF 
SET 

[1 ] : REPORT 1 ( .Z) 5 

C2] : REP0RT2( *Z) 5 

C4 >73 ; = ,Z+1 5 

[INRANGE3 : ERROR! ( ,Z) 5 
[OUTRANGE] s ERROR2(,Z)5 

tes; 

The interpretation of this expression begins with the evaluation of .X; then, 
depending on the value of .X, one of five actions is taken. If the value is 1, the 
routine REPORT1 is called. If the value is 2, the routine REPORT2 is called. 
If the value is 4 or 7, the assignment Q = .Z+l is performed. If the value is in 
the range from 1 to 8 but is none of the previous cases, then the routine 
ERROR1 is called. If the value is outside of the range 1 to 8, then the routine 
ERROR2 is called. 

A third construct for alternative flow of control is the select-expression, which 
lies between the conditional-expression and the case-expression in its degree 
of specialization. 

1.4.10 Loops 

Iterative actions are controlled by loop-expressions. An example of the use of a 
loop-expression is: 

OWN 

SUM » 

LIST: VECTOR [21 35 

♦ t ♦ 

SUM = Oi 

I NCR I FROM TO 20 DO 

SUM = .SUM + .LISTC .13 5 

The loop-expression in this example forms the sum of the 21 elements of the 
vector LIST. It does so by executing the assignment 21 times, once each for .1 
equal to 0, 1, 2, and so on through 20. In this example, the loop-expression is 
followed by a semicolon and is therefore used in a statement-like way. Note 
that the 'control parameters' (0 and 20 in this case) can be any form of 
expression that has a value. 

A second example of the use of a loop-expression is: 

OWN 

)•( t 

LIST; UECTOR[2135 

♦ ♦ ♦ 

X = ( I NCR I FROM TO 20 DO 

IF .LIST[,I3 E0L THEN EXITL00P .1)5 

The loop-expression in this example searches the vector LIST for an element 
that is 0. If a is found, the value of the loop-expression is .1; that is, a value 
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between and 20 that shows where the was found. If a is not found, the 
loop runs to completion and the value of the loop-expression is (by definition) 
-1. In this example, the value of the loop-expression is used to provide, in a 
convenient way, for the case that there is no in LIST. 

1.4.11 Binding of Names 

Most of the names in a BLISS program represent addresses — either data 
addresses or routine addresses. The operation of associating an address with a 
name is called binding. Once the name is bound, the use of the name becomes 
equivalent to the use of the address to which it is bound. 

As an example of binding, consider the following use of the name BETA: 

OWN 

BETA ! 

+ ♦ ♦ 

BETA = 4 5 

Suppose that BETA is bound to the address 1203. Then the assignment in the 
example is equivalent to: 

1203 = a; 

In nearly all cases, the programmer does not know or care to know the address 
to which a name is bound. Storage is allocated by the compiler, the linker, 
and the operating system, and the programmer simply wants references to 
storage to be consistent. 

Occasionally, a programmer does want to access a particular location. Sup- 
pose, for example, that a fullword used for communication with a certain 
input/output device is in location 80. Then that location can be set as follows: 

BIND 

ION = 80 5 

♦ ♦ ♦ 

iow = o; 

In this case, the assignment is entirely equivalent to 

so = o; 

The use of the BIND declaration makes the intentions of the programmer 
clear, not only to the reader but also to the compiler. 



1 .5 Program Transportability 



Transportability of software is the use of the same source program in more 
than one system environment. The basis for transportable programming in 
BLISS is the extensive language base referred to as Common BLISS. In addi- 
tion, BLISS provides many specific facilities that aid in achieving transporta- 
bility along with efficiency, either through (1) parameterization of Common 
BLISS constructs, or (2) conditional or compartmented use of dialect-specific 
code. 
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The major facilities that support transportable programming are the follow- 
ing: 

• Predefined data structures, e.g. VECTOR, BITVECTOR, BLOCK, that 
allow commonly used data structures to be allocated and accessed effi- 
ciently in each target environment. 



• 



Predefined literals, that reflect the parameters of the target architectures 
in terms of bits. These literals can be used, for example, to parameterize 
data declarations and storage references for greatest efficiency on each 
intended target system. 

A listing of the predefined literals and their values for each target system 
follows. 



• 









Value in: 




Name 


Meaning 


BLISS-16 


BLISS-32 


BLISS-36 


%BPVAL 


Bits per 










BLISS value 


16 


32 


36 


%BPUNIT 


Bits per 










addressable unit 


8 


8 


36 



%BPADDR Bits per 

address value 16 32 18 or 30 ' 

%UPVAL Units per 

BLISS value 2 4 1 

(1. Depending on the target-system CPU.) 

• User-definable data structures and named fields. The structure definition 
is a representation of the accessing algorithm, and it can make use of the 
predefined literals to provide field packing that is optimal for each target 
architecture. 

• Character string functions, that permit efficient manipulation of string 
data regardless of the representation on the target architecture. Exam- 
ples: CH$PTR creates a character-string pointer, CH$MOVE moves a 
character string, and CH$COMPARE compares the value of two strings. 
There are approximately 25 such functions. 

• Compile time conditionals, that allow compiled code to be explicitly dif- 
ferent for different target architectures. 



Powerful macro facility, that allows for different expansions for different 
target systems, e.g. %BLISS32(BYTE) expands to its parameters (BYTE 
in this case) only if being compiled by the BLISS-32 compiler. Macros 
can also be used to segregate code sequences that differ for each architec- 
ture. 
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REQUIRE and LIBRARY files. Sets of common definitions can be kept in 
files that are selectively included in compilations through use of the RE- 
QUIRE or LIBRARY declarations. This is a simple and efficient method 
of sharing common data structures and definitions between modules in a 
conditional fashion. It also permits compile-time conditionals and 
parameterized definitions to be maintained separately from the code in 
the modules. 



1.6 Effects of Optimization 

The semantic definitions of the BLISS language in this manual describe the 
useful, perceptible results of program execution as if those results were 
achieved without optimization of the object code. Wherever possible, then, 
the manual avoids discussion of how the results are actually obtained. The 
only exceptions are where a discussion of object code enables the programmer 
to make a more efficient choice between several alternative constructs, for 
example, between two types of control expressions. In particular, the opti- 
mization strategies employed by the compiler are not described. The opti- 
mizations reduce the cost of program execution, by eliminating some of the 
actions defined by the language semantics, but they never affect the final 
results. 

In some cases, however, the optimizations can be so extensive (global flow 
optimizations) that the object code generated does not show any obvious 
correlation to the corresponding sequence of source code. The degree of opti- 
mization performed by the compiler can be controlled by optimization 
switches, either in the module head (Chapter 19) or in the compiler command 
line. The BLISS user's guides describe the kinds of optimizations performed 
and the effect of the various optimization switches. 

1.7 The BLISS Programming System 

The BLISS programming system is the collection of software programs that 
supports the development of BLISS programs. Some of the components of the 
BLISS system are used only for BLISS programs; the compiler is an example. 
Other components are shared with other programming language systems; the 
linker is shared in this way. 

Operating instructions for the compiler or the linker are not given here. Such 
instructions are essential (and are given in the appropriate BLISS user's 
guide), but they never, or almost never, affect the results of program execu- 
tion as described in this manual. 

This section describes the components of the BLISS system and then goes on 
to talk about the evaluation of constant expressions by two components of the 
system, the compiler and the linker. 

1.7.1 System Components 

The BLISS system has five main components: the compiler, the linker, the 
operating system, a debugging package, and a set of utilities. These compo- 
nents are briefly described in the following paragraphs. 
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The compiler is especially written for the BLISS system (one for each dialect). 
It accepts a BLISS module as its input or source file. It produces an unlinked 
target-system program as its object file (although the compiler used for a 
given dialect may itself actually execute on another computer system, i.e., 
may be a cross-compiler). Because, as discussed above, the compiler performs 
complicated and large-scale optimizations, the relationship between the 
source file and the object file is sometimes difficult to perceive; that is, it can 
be difficult to find the specific instructions that implement a particular 
BLISS expression. Therefore, a plan for developing a BLISS program should 
involve as little reference to the object file as possible. 

The compiler takes only one module at a time as its input. Therefore, the 
compiler cannot determine addresses that are used in the given module but 
declared in other modules; such addresses are external and must be left blank 
(unlinked in the object file). Furthermore, the compiler does not determine 
the absolute addresses of routines and data. Instead, the compiler expresses 
addresses as offsets relative to certain base addresses. 

The linker is a target-system utility program that is shared by all of the 
programming languages for the target system. It accepts an unlinked object 
program, produced by the compiler, for each module of a program. It produces 
an executable program image as its output. 

The linker takes up where the compiler leaves off, and finishes the job of 
preparing the program for execution. It has access to all modules of the pro- 
gram and can therefore fill in the external addresses. It can determine the 
required base addresses for routines and data and can therefore replace static 
offset addresses with absolute addresses. 

The operating system is a collection of target-system utility programs that are 
essential to any programming job. It includes a command that executes a 
program. This command loads the program image and starts execution. 
Thereafter, the operating system manages input/output, handles interrupts, 
and generally oversees program execution. 

The debugging package is a program that assists a programmer in checking 
out a program. The package includes features for dumping data in convenient 
representations and formats, for tracing data through the execution of the 
program, for establishing break points to halt program execution, and so on. 

The BLISS utilities are a collection of programs especially written to support 
the BLISS programming process. One such utility, for example, is the BLISS 
source-program formatter. The utilities are described in the BLISS User's 
Guides and in on-line documentation files available with each BLISS system. 

1.7.2 Constant Expressions 

When the value of an expression cannot change throughout program execu- 
tion, it is a constant expression. Many important techniques for optimizing a 
program depend on the recognition and evaluation of constant expressions. 

Some constant expressions can be evaluated as soon as they are written down. 
For example, the value of the numeric-literal 52 is obviously fifty-two. Other 
constant-expressions depend on addresses that are determined either by the 
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compiler or by the linker. For example, the value of the expression X+6 
depends on the address that is associated with X. 

When the value of a constant expression is determined, the expression is 
bound. The process of associating values with constant expressions is a form 
of binding. These terms are most often applied to names; however, in BLISS a 
name is just a special case of an expression, and a bound name is just a special 
case of a bound expression. The main activity of the linker is to bind the 
names used in a program to appropriate addresses. 

In certain contexts, BLISS requires a compile-time-constant-expression; that 
is, an expression that can be bound by the compiler. For example, when a 
VECTOR data segment is declared, its size must be given as a compile-time- 
constant-expression; this restriction permits the compiler to allocate storage 
for the data segment and thus avoid the expense of dynamic storage alloca- 
tion. 

Since the compiler does not determine absolute addresses, a compile-time- 
constant-expression usually cannot depend on a name that represents an ad- 
dress. The exception occurs in expressions such as X-Y or X EQLA Y; in 
these expressions, the offset addresses for X and Y (which are determined by 
the compiler) are sufficient to determine the values of the expressions. 

In certain other contexts, BLISS requires a link-time-constant-expression; 
that is, an expression that can be bound by the linker. Since all addresses are 
determined by the linker, a link-time-constant-expression can depend on a 
name that represents an address. Further details about both compile- and 
link-time-constant-expressions are given in Chapter 7. 

Much of BLISS programming can be done without regard for the fact that a 
program goes through compilation and linking before it can be executed. The 
compile- and link-time-constant-expressions are important exceptions to this 
rule. 



1.8 A Complete Program 



An example of a complete program follows. The purpose of the example is to 
illustrate the overall structure of a BLISS program. The example is not a 
realistic program, although it is executable. A realistic program would require 
many pages for its listing as well as many pages of explanation. Instead, the 
example is a short program that reads a number from the terminal, adds one 
to it, and prints out the result. 

The program is composed of two modules, TIO and El. The first module, 
TIO, is assumed to be a general-purpose library module that performs 
input/output at the user's terminal. It includes an input routine, GETNUM, 
that reads a number that has been entered at the terminal, and an output 
routine, PUTNUM, that prints a given number at the terminal. The module 
TIO is not listed here. 
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The second module, El, is the specialized portion of the example program. It 
controls the entire process and performs the specified operation (the addition 
of 1) on the given data. This module is presented here. 

MODULE El (MAIN = CTRL) = 
BEGIN 

FORWARD ROUTINE 
CTRL » 

step; 
routine ctrl = 

+ 

This routine inputs a value* operates on i t » and 
then outputs the result* 



BEGIN 

EXTERNAL ROUTINE 

G E T N U M » ! Input a number from t e r m i n a 1 
P U T N U M 5 ! Output a number to t e r m i n a 1 

LOCAL 

X • ! Storage for input value 

Y 5 ! Storage for output value 

GETNUM(X) 5 

Y = STEP( . X) ; 

PUTNUM( ♦ Y) 

end; 
routine step(a) = 



This routine adds 1 to the d i v e n value* 

( , A+l ) 5 

END 
ELUDOM 

An informal discussion of this module follows. Only the main features are 
mentioned, and some new terminology is introduced. The purpose is to give a 
general idea of how a module is constructed and how it works. 

The module includes comments, each of which begins with an exclamation 
mark. Not included, however, is a long comment that normally appears at the 
beginning of a module and provides information about copyright, authorship, 
revisions, and so on. 

The outer structure of the module is: 

MODULE El (MAIN = CTRL) = 
BEGIN 



END 
ELUDOM 
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The first line gives the name of the module, El. It also specifies that the main 
routine for the entire program is CTRL; therefore, when the program is exe- 
cuted, the operating system will call CTRL. The three dots represent the body 
of the module. 

The body of the module begins with a forward-routine-declaration, which lists 
the names of the routines that are declared in the module. The remainder of 
the body is devoted to the declarations of the routines. 

The first routine-declaration begins with the line: 

ROUTINE CTRL = 

This line gives the name of the routine, CTRL. Because CTRL is not followed 
by a parenthesized list of names, the routine is not called with parameters. 
The purpose of the routine is to control program execution and to call other 
routines. 

The body of the routine CTRL is given after the comment that describes the 
routine. It contains two declarations followed by three expressions. The decla- 
rations do not cause actions directly; instead, they describe the names that 
are used in the routine. The first declaration describes GETNUM and 
PUTNUM as names of routines that are declared in another module. The 
second declaration describes X and Y as the addresses of storage segments 
that are used during execution of this routine. 

The three expressions are: 

GETNUM(X) i 

Y = STEP( . X) i 

PUTNUM ( , Y> 

The first two expressions are terminated (followed by a semicolon), the third 
is not. These expressions specify separate actions, and are executed (or more 
precisely, evaluated) one after another, in the order written. The first expres- 
sion calls upon the routine GETNUM to read a number from the user's 
terminal and store it at address X. The second expression calls upon the 
routine STEP to add 1 to the contents of X and then assigns the result to Y. 
(The values of the first two expressions are discarded; thus these expressions 
are used in a statement-like way, solely for their side effects.) 

The third, non-terminated expression calls upon the routine PUTNUM to 
print the contents of location Y at the user's terminal, but also provide a value 
for the routine as a whole. This is the value of the routine call, presumably a 
completion code returned by PUTNUM. (One target operating system, 
VAX/VMS, requires such a value to be returned by the main routine. In the 
case of other target operating systems, the main-routine return value, if pro- 
vided, is simply ignored.) 

The second routine-declaration begins with the line: 

ROUTINE STEP(A) = 

This line gives the name of the routine STEP. It also gives a formal name, A, 
that represents the parameter of the routine. Because there is no NO VALUE 
attribute, this routine also returns a value. 
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The body of the routine STEP is given after the comment that describes the 
routine. It is a single line, as follows: 

( . A+i ) ; 

This line specifies that when this routine is called, the value it returns is 
calculated by adding 1 to the contents of formal location A, the value of the 
parameter. Observe that the semicolon here is simply the terminator of the 
routine declaration, and as such does not terminate the expression. It has no 
effect upon whether or not the routine returns a value. 

The expression that constitutes the routine body is enclosed in parentheses for 
added clarity; the effect would be exactly the same without the parentheses in 
this case. An equivalent way of expressing this routine declaration, which 
shows more clearly the role of the semicolon, is the following: 

ROUTINE STEP(A) = 

+ 

This routine adds 1 to the & i u e n value* 

BEGIN 
. A+l 

end; 

Section 1.4.6 discusses the equivalence of the parenthesis pair and the 
BEGIN-END pair as used in these examples. 
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Chapter 2 

Lexical Definitions and Syntax Notation 



This chapter defines lexemes (the basic syntactic elements of BLISS), and the 
rules for the formation of valid BLISS source text. It also describes the syntax 
notation used in later chapters to define the larger constructs of the BLISS 
language. 

The basic elements and rules defined here are the following: 

• Characters and linemarks. Characters are the indivisible units of pro- 
gram text. Linemarks serve to divide a character sequence into separate 
"lines" of source text. Together they constitute the lowest-level elements 
of syntactic structure. 

• Lexemes and spaces. The lexemes of BLISS are analogous to the words 
and punctuation marks of ordinary English text. The spaces are used to 
separate lexemes where necessary and, optionally, to arrange the program 
text in a clear and attractive way. Together they constitute the next 
higher level of syntactic structure. 

Note that a comment in BLISS is simply a special form of a space from 
the lexical viewpoint. 

• The separation rules, which govern the mandatory and optional use of 
spaces to separate lexemes. 

The syntax notation, described in the last section of this chapter, is used to 
formulate the syntactic rules that define the many constructs of the BLISS 
language. Each such construct consists of one or more lexemes. Thus these 
higher-level syntactic rules fundamentally depend upon the separation rules 
for their formal interpretation, although the separations required and allowed 
by the syntactic rules are usually intuitively obvious without recourse to the 
separation rules. 

2.1 Characters and Linemarks 

At the lowest level of syntactic structure a BLISS module consists of a se- 
quence of characters and linemarks. They are the smallest recognizable ele- 
ments of the source text. 



2-1 



2.1.1 Characters 

The characters that can appear in a module are listed and classified in the 
following table:, 



Characters 














Printing Characters 














Letters: ABC... 


Z a 


b c ... 


z 








Digits: 12.. 


9 












Delimiters: . " * / 


+ - 


> > 


( ) [] 


< > 






Special Characters: 


$- 


_ % ! 


' 








Free Characters: " 


# & 


? @ \ 


Ml} 


- 






Nonprinting Characters. 




blank 


tab 


vertical-tab 


form 


-feed 



All of the characters in this table are members of the ASCII character set. 
However, the table does not include all of the ASCII characters. Specifically, 
30 of the 34 nonprinting ASCII characters do not appear in the table and must 
not be used in a BLISS module. 

Note that this table shows which characters can be used in a BLISS program, 
and does not impose a restriction on data. BLISS data can use any ASCII 
characters. (The characters that cannot be represented literally in the pro- 
gram text can, however, be entered indirectly, using numeric codes, via the 
%CHAR lexical-function described in Chapter 15.) 

2.1.2 Linemarks 

The linemark is the separation between the end of one source line and the 
beginning of the next in a program-text file. On most terminals, it is entered 
into the program text by pushing the RETURN, CARRIAGE RETURN, or 
NEWLINE key. 

The linemark is represented in different ways in different target systems. On 
the PDP-11 and VAX-11 systems, where a text file is a sequence of records, 
the linemark is represented by the division between two successive records. 
On the DECsystem-10 and DECSYSTEM-20, where a text file is a single 
character string, the linemark is represented by a line-feed, vertical-tab, or 
form-feed character; if any of these characters is immediately preceded by a 
carriage -return character, then that character is also part of the linemark. 



2.2 Lexemes and Spaces 



At the next higher level of syntactic structure a BLISS module consists of a 
sequence of lexemes and spaces. A lexeme is the smallest meaningful unit of 
the source text. Spaces are used to separate certain kinds of lexemes according 
to the separation rules, and are optionally used to separate other lexemes for 
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greater readability and general formatting purposes. The division of a module 
into lexemes and spaces is especially important for the interpretation of 
macros, as described in Chapter 15. 

2.2.1 Lexemes 

The various types of lexemes that can appear in a module are listed and 
classified in the following table, with examples for each type except delimiters 
(single characters that are completely enumerated): 



Lexemes 




Keywords: ROUTINE %ASCIZ AND 




Names 




Predeclared: VECTOR MAX 




Explicitly Declared: X BETA26 INITIAL. 


SIZE 


Decimal Literals: 23000 




Quoted Strings: 'ABC 'He said, "Go!" 


' '77700' 


Delimiters 




Operators: . A * / + - = 




Punctuation Marks: ,;:()[]<> 





A delimiter serves either as an operator or as a punctuation mark. These 
lexemes are called delimiters because they never "run into" a neighboring 
lexeme. For example, the delimiter "+" can be used to form the expression 
"ALPHA+1" (consisting of three lexemes) without using blanks. But an at- 
tempt to use the keyword "AND" without adjacent blanks results in "ALP- 
HAAND1", interpreted as a single lexeme. 



2.2.2 Spaces and Comments 

When two lexemes would otherwise "run together" to make a single lexeme, 
they must be separated by a space. A description of spaces is given in the 
following table: 



Spaces 




Linemark 




Nonprinting Characters: 


blank tab vertical-tab form-feed 


Comments 




Trailing Comment:: 


! This is a program for entomologists. 


Embedded Comment: 


%{ Insert new routine here )% 
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The preceding table describes spaces informally, using two examples for the 
comments. A more precise definition is: 

1. A space is a linemark, a nonprinting character (as listed in the table) or 
a comment. 

2. A comment is a trailing comment or an embedded comment. 

3. A trailing comment is an exclamation character followed by the remain- 
der of the line on which the comment begins. 

4. An embedded comment begins with the two characters "%(", followed 
by the text of the comment, followed by the two characters ")%". The 
text must not contain the sequence ")%", since that would prematurely 
end the comment; see guidelines below. An embedded comment can 
begin after any lexeme of a module and can extend to any later position 
in the module. However, an embedded comment must end in the same 
source file in which it began. 

When a module is written by the programmer, spaces are commonly used to 
arrange the module in a clear and attractive format and to insert comments 
on the workings of the program. However, when a module is translated by the 
compiler, the only role of spaces is to separate the lexemes of the module. 
From the point of view of the compiler, for example, a lengthy comment is 
equivalent to a single blank character. 

2.2.2.1 Guidelines on the Use of Comments — A trailing comment, beginning 
with the "!" character anywhere in a source line, is terminated by the next 
linemark, i.e., by the 'end of the line' in which it occurs. Thus it is a generally 
safe and unambiguous form of commment and can be used, for example, to 
"comment out" any line of source text whatever its content. 

An embedded comment, beginning with the character sequence "%(", is ter- 
minated by the very next occurence of the sequence ")%". This means that 
the embedded comment cannot be nested. Also, the sequence ")%" is a valid 
though ill-advised form of ending of a macro definition (see Section 15.2). 
Thus an extensive embedded comment could be inadvertently terminated by 
the occurence of ")%" in a macro declaration where the "%" character was 
intended to terminate a macro definition. For these reasons the embedded 
comment should be used with care. Also, its use to "comment out" a body of 
code is discouraged. 



2.3 The Separation Rules 



The use of spaces between the lexe.nes of a module is governed by the separa- 
tion rules. The rules are: 

1. One or more spaces must appear between two lexemes if each lexeme is 
any one of the following: 

• A name, 

• A keyword, or 

• A decimal-literal. 
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This rule requires the use of spaces wherever two lexemes would other- 
wise merge to form a single, longer lexeme. 

2. One or more spaces may appear between any two lexemes. This rule 
permits the use of spaces to control format and provide comments. 

3. A space must not be inserted into a lexeme. This rule prevents a lexeme 
from being broken into two lexemes. Some apparent exceptions arise in 
the case of a quoted-string lexeme, as described in Sections 4.3.2. 



2.4 The Syntax Notation 



The syntax of BLISS is a collection of syntactic rules that describe the con- 
struction of a module (the unit of compilation). The special notation used for 
the syntactic rules is defined in this section. 

Each syntactic rule defines a syntactic name. The syntactic rules are interde- 
pendent; that is, many of the rules define a syntactic name in terms of other 
syntactic names. However, the rules do not form a vicious circle of definitions 
because some of the rules define syntactic names directly in terms of syntactic 
literals, i.e., without reference to other syntactic names. 

The ultimate syntactic name is module, which is defined in the syntactic rules 
given in Chapter 19. The description of the language begins with the cjefini- 
tion of the syntactic name expression, in Chapter 4. 

2.4.1 Syntactic Rules 

A syntactic rule is divided into two parts by a vertical line. To the left of the 
line is the syntactic name that is defined by the rule; to the right, a string 
definition. In the simplest rules, the string definition is a single character or a 
single syntactic name. 

In more complicated rules, string definitions are combined to make larger 
string definitions as follows: by concatenation (the joining of strings), by 
disjunction (the choice between two strings), or by iteration (the joining of 
several copies of a string) . 

An example of the simplest possible kind of rule is: 



dollar 


$ 



In English, this rule reads: 'The syntactic name dollar designates the single 
character "$".' Note that the character "$" is a syntactic literal, as defined in 
the following section; thus this rule completely defines the syntactic name 
dollar, without reference to any other rules. 
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Sometimes it is useful to give the same definition for several syntactic names. 
In such a case, the several names are written one above another and are joined 
by a brace. 




In English, this rule reads: 'The syntactic names position and size each desig- 
nate an expression.'' 

2.4.2 Syntactic Names and Syntactic Literals 

A syntactic name is one or more English words composed of lower case letters 
and connected by hyphens. Four examples of syntactic names are given in the 
two syntactic rules above, namely: dollar, position, size, and expression. 

Further examples of syntactic names are: 

module 
own -item 

forward-routine-declaration 
compile-time-constant-expression 

Every syntactic name has at least two characters. 

A syntactic literal is a printing character that is interpreted as itself when it 
occurs in a string definition. All printing characters are syntactic literals 
except: 

1. A character that is part of a syntactic name. 

2. A brace character, { or }, or a vertical bar, I. 

3. A period or comma that is part of the sequence "..." or the sequence 

, .. . 

In practice, it is easy to distinguish a syntactic name from a syntactic literal 
because syntactic names are always in lower case and BLISS keywords appear 
in this manual (by convention) in upper case. 

2.4.3 Concatenations 

A concatenation is a string definition composed of a sequence of two or more 
string definitions. If the definitions are adjacent (without intervening spaces), 
then the strings they define must also be adjacent. If the definitions are 
separated (by spaces), then the strings they define may or may not require 
separation, depending on the separation rules given in Section 2.3. 

An example of a syntactic rule that uses adjacent concatenations is: 



volatile-attribute 



VOLATILE 
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In English, this rule reads: 'The syntactic name volatile-attribute designates 
the following string: the keyword "VOLATILE".' Because the eight letters 
"VOLATILE" (each one a syntactic literal) are adjacent in the rule, they 
must also be adjacent in the program. 

An example of a rule that uses both adjacent and separated concatenations is: 



exitloop-expression 



EXITLOOP exit-value 



In English, this rule reads: 'The syntactic name exitloop-expression desig- 
nates the following string: the keyword "EXITLOOP", followed by an exit- 
value.' 

In the English reading of any syntactic rule, the phrase "followed by" is an 
abbreviation for "followed by the spaces (if any) that are required by the 
separation rules, followed by". 

2.4.4 Disjunctions 

A disjunction is a string definition that permits a choice of one string defini- 
tion from a set of several string definitions. The set of definitions is enclosed in 
braces. Each definition is separated from the preceding one by being on, a new 
line or by a vertical-bar character. 

An example of a disjunction in which each choice is written on a separate line 
is: 



case-label 



(single-value \ 

low-value TO high-value I 

INRANGE I 

OUTRANGE / 



In English, this reads: 'The syntactic name case-label designates one of the 
following strings: (1) a single-value, (2) a low-value followed by the keyword 
"TO" followed by a high-value, (3) the keyword "INRANGE", (4) the key- 
word "OUTRANGE".' 

An example of a disjunction in which the choices are separated by vertical-bar 
characters is: 



octal-digit 



{ I 1 I 2 I — 17} 



In English, this reads: 'The syntactic name octal-digit designates one of the 
following characters: "0", "1", "2", and so on to "7".' Observe that once the 
set of choices is clearly implied, the ellipsis symbol " — " is used to indicate 
other choices. In some disjunctions, one of the choices may be the omission of 
a construct; in such a case, the word "nothing" is included in the braces. 
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An example of a disjunction that uses the word "nothing" as one of the 
choices is: 



leave-expression 



LEAVE label 



WITH exit-value ) 
nothing J 



2.4.5 Replications 

A replication is a string definition that represents a sequence of one or more 
copies of a given string definition. The replication is indicated by writing the 
symbol "..." after the given definition. The separation between the defined 
strings is determined by the separation rules, just as for concatenation. 

An example of a replication is: 



own-time 



own-name 



: own-attribute 
nothing 



In English, this rule reads: 'The syntactic name own-item designates the 
following string: an own-name followed by an optional own-attrihute-list. An 
own-attribute-list is a colon followed by a sequence of one or more own- 
attributes.'' (The extra syntactic name, own-attribute-list, is introduced only 
for the sake of the English reading.) 

A special kind of replication is indicated by writing the symbol ",..." after the 
definition. The symbol means that each copy of the given definition is sepa- 
rated from the preceding one by a comma. 



An example of a replication that uses the symbol 



is: 



routine-call 



routine-designator ( ( actual ,... ) 
( nothing ) 



In English, the rule reads: 'The syntactic name routine-call designates the 
following string: a routine- designator, followed by the character "(", followed 
by an optional actual-list, followed by the character ")". An actual-list is a 
sequence of actuals that are separated from one another by commas.' (The 
extra syntactic name, actual-list, is introduced only for the sake of the English 
reading.) 

Note that in either case ("..." or ",..."), the optional replication applies only 
to the string definition that immediately precedes the replication symbol. 

2.4.6 Dialectal Differences 

Some of the syntactic rules given in this manual apply to only one or two of 
the three BLISS dialects. That is, some of the rules are not part of Common 
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BLISS. Further, certain of the string definitions given within some rules are 
dialect specific. 

These dialect-specific features are indicated in the syntax diagrams by 'flags' 
of the form 

nn Only => or mm/nn Only => 

preceding a rule (or group of rules) for the former case; or a flag of the form 

<= nn Only or <= mm/nn 

following a string definition for the latter case. In each case, mm and nn 
identify the dialect(s) to which the syntactic feature applies, i.e., 16, 32, or 36. 

An example of an entire syntactic rule that is dialect-specific is: 



16/32 Only => 
extension-attribute 



SIGNED ) 
UNSIGNED J 



In English, the dialect flag means: 'The following syntactic rule applies to the 
BLISS-16 and BLISS-32 dialects only.' 

An example of both a syntactic rule and a string definition within the rule 
that are dialect-specific is: 



16/32 Only => 
allocation-unit 



( LONG ) 
\ WORD S 
( BYTE ) 



LONG ) <= 32 Only 

WORD 

BYTE 



In English, the left-pointing dialect flag "<= 32 Only" means: 'The string 
definition LONG is valid only in BLISS-32 as an alternative within the rule 
for allocation-unit (which itself applies only to the BLISS-16 and BLISS-32 
dialects).' 
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Chapter 3 

BLISS Values and Data Representations 



The range of data values permitted and the kinds of data representations 
available are important characteristics of a programming language. Because 
the BLISS language is a systems implementation language, its value and data 
representations are closely related to those directly provided or efficiently 
handled by the machine architecture of each target system. 

This chapter describes the values and data representations provided by each 
BLISS compiler/dialect. Because the three BLISS target systems (or system 
families) have substantially different architectures — word sizes, addressable 
units, character string representations, etc. — certain portions of this chapter 
are, necessarily, quite system specific. 



3.1 BLISS Values 



BLISS provides a variety of written (source program) representations for val- 
ues (binary, octal, hexadecimal, and so on). These are described in Chapter 4. 
The normal representation is decimal; that is, any number in a BLISS pro- 
gram and in this manual, is interpreted as decimal notation unless otherwise 
indicated. 

The values on which the object program operates, however, are represented as 
bit strings. The maximum-length bit string that is efficiently accessable by a 
given target system (i.e., a "word" or "longword" depending on the system) is 
called a fullword in BLISS terminology. The length of a fullword, in bits, for 
each target system is indicated by the numeric portion of the name of the 
respective dialect: 16, 32, or 36. 

A bit string that is shorter than a fullword is called a field value. Several field 
value sizes are of particular importance in BLISS, depending upon the dialect 
in question: 

• For All Dialects — The bit, which is the smallest unit of storage. 

• For BLISS-16 — The byte (8 bits), which is the basic addressable unit in 
PDP-11 and VAX-11 systems. 
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• For BLISS-32 — The byte, as above, and the word (16 bits), which is the 
'intermediate size' addressable unit in VAX-11 systems. 

Fullword values and field values play contrasting roles in BLISS. Fullword 
values are used as the basis for all calculations. Fields are used to achieve 
compact storage for values that do not require the maximum-length bit string 
for their representation. The two kinds of values are discussed separately in 
the following sections. 

3.1.1 Fullword Values 

The fullword value (formerly called "a BLISS value") is the fundamental 
data type of BLISS. Specifically, the result of evaluating any BLISS expres- 
sion is a fullword value. 

In some cases, a fullword value can be viewed as a bit string without a specific 
interpretation, as when a value is moved from one storage location to another 
without modification. In other contexts, the bits of a fullword value are given 
a specific interpretation. A fullword value can be interpreted as: 

• A signed integer, represented in two's complement notation. 

• An unsigned integer. 

• A sequence of character positions, each of which contains a code for an 
ASCII character. 

• A sequence of logical values, each of which represents "true" or "false". 

• A memory address. 

Other interpretations for a fullword value can be devised, but these are the 
interpretations that are built into the operations of BLISS. 

The length of a fullword, in bits, is given in each BLISS dialect by the 
predeclared literal %BPVAL (bits per value), i.e., 16, 32, or 36 for BLISS-16, 
BLISS-32 and BLISS-36, respectively. Using this literal, the range of a full- 
word value for each of the interpretations listed above can be expressed for all 
dialects as follows: 

• Signed integer, i: 

-<2**XBPVAL-i ) < i < (2**'«BPVAL-1 )-l 

In BLISS-16, for instance: -<2**15> < i < <2**i5)-i 

• Unsigned integer, i: 

< i < (2**XBPgAL) -1 

• ASCII character positions: 

2 in BLISS-16 

4 in BLISS-32 

5 in BLISS-36 
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• Sequence of logical (boolean) values: 

XBPVAL 

• Memory address: 

Full address space of each target system 

A fundamental rule of BLISS is the following: 

The interpretation of a fullword value is supplied by the context in which 
the fullword value is used. A given fullword value can have one interpreta- 
tion in one context and a different interpretation in another context. 

In this respect, the BLISS language is similar to machine language and is 
different from most high level languages. Both BLISS and the target-system 
hardware interpret a value according to the operation applied to it. In con- 
trast, most high level languages associate a specific interpretation (or "type") 
with each value, independent of its context. 

The BLISS rule for interpreting fullword values allows programmers to stay 
close to the hardware and, accordingly, to write more efficient programs. At 
the same time, however, this rule permits programming errors to arise as a 
result of the misinterpretation of values. 

As a basis for an example of the interpretation of a fullword value, consider 
the following assignment: 



This assignment sets the contents of X to the two's complement representa- 
tion of minus one; that is, a sequence of %BPVAL ones. The two expressions 
that follow interpret the contents of X in different ways: 

.;■< lss a 

• ;•< lssu a 

Both of these expressions use a less-than operator to compare the contents of 
X to 4. They yield 1 or depending on whether or not the contents of X is less 
than 4. However, according to the definitions given in Chapter 5, the opera- 
tors interpret their operands in different ways, as follows: 

• The LSS operator interprets its operands as signed integer values. It finds 
that the contents of X is -1 and is therefore less than 4. Accordingly, the 
value of the expression is 1. 

• The LSSU operator interprets its operands as unsigned integer values. It 
finds that the contents of X is a large positive integer (namely, 
(2**%BPVAL)-1) and is therefore not less than 4. Accordingly, the value 
of the expression is 0. 

Since the negative number was assigned to X, it might be assumed that the 
user of the LSSU operator is incorrect. In fact, however, both expressions are 
valid. The question of which is correct depends entirely on the intentions of 
the programmer. 
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3.1.2 Field Values 

According to the definition already given, a field value is a bit string that is 
shorter than a full word. Field values arise in two ways, as follows: 

• Some stored values are "packed" and occupy only part of a fullword. 

• Some BLISS operators and literals have values that can be represented in 
less than %BPVAL bits. 

Whenever a field value arises during program execution, it is extended to 
become a fullword and then the appropriate interpretation is applied to the 
fullword. The rules for the extension of values follow. 



3.1.3 The Extension of Values 

A field value is extended to a fullword value by placing a sufficient number of 
bits at the left end of the given value to provide a total of %BPVAL bits. 

The following discussion of value extension is largely oriented toward 
BLISS-16 and BLISS-32, since the target systems for these two dialects allow 
allocation of scalar data segments in smaller-than-fullword units. Hence these 
dialects have an allocation-unit and an extension-attribute that can be used 
in data declarations. As will be seen in Chapters 5 and 11, however, these 
syntactic features are closely related to field-selectors, which are common to 
all three dialects. To the extent, then, that field values can arise in BLISS-36 
as well as in BLISS-16 and BLISS-32, the following discussion is equally 
applicable to all dialects. 

A value can be extended in two ways, as follows: 

• Unsigned extension uses a zero bit for each additional bit. 

• Signed extension uses a copy of the sign bit (leftmost bit) of the given 
value for each additional bit. 

The kind of extension is determined in either of two ways. First, in 
BLISS-16/32, an extension-attribute (UNSIGNED or SIGNED) can be in- 
cluded in the declaration of a data segment name (see Section 9.2). Second, a 
sign-extension-flag can be used in a field-selector (see Section 11.2). When the 
kind of extension is not explicitly given by an extension-attribute or a sign- 
extension-flag, unsigned extension is assumed as the default. 

BLISS-16/32 ONLY 

As the basis for some examples of value extension, consider the following 
declaration which is valid in BLISS-16 or BLISS-32: 

OWN 

X: BYTE SIGNED* 
Y: BYTE5 

Suppose the contents of both X and Y are: 

11111111 (binary) 

The declaration of X as SIGNED implies that this value is -1; that is, the 
two's complement interpretation of the given bit string. On the other hand, 
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the declaration of Y as UNSIGNED (by default, since no extension-attrib- 
ute is given) implies that its contents is 255; that is, the unsigned interpre- 
tation of the given bit string. 

(These declarations are invalid for BLISS-36 simply because the target- 
system architecture does not permit storage allocation in units of less than 
%BPVAL bits, i.e., less than a 36-bit machine word. Fetching and storing of 
field values can be performed, however, through the use of explicit field- 
selectors, as illustrated in a later example.) 

The sign interpretations come into play when the contents of X and Y are 
fetched. The evaluation of .X uses signed extension to produce the following 
bit string: 

11111. ..1111111111 (binary) 

which is the two's complement representation of -1 represented in 16 bits 
for BLISS-16 or 32 bits for BLISS-32. In contrast, the evaluation of .Y uses 
unsigned extension to produce the following bit string: 

00000.. .0011111111 (binary) 

which is the unsigned representation of 255. Therefore, the two results are 
different, and the expression 

.X EQL .Y 

would be false (that is, the low bit would have the value 0). 

In BLISS-36 as well as BLISS-16 and BLISS-32, identical results would be 
obtained using the following, analogous set of declarations and fetch opera- 
tions: 

OWN 

X f 
Y 5 

declares X and Y as the names of fullword, scalar data segments. Assume that 
the low-order eight bits of both these full words are one-bits. Then the fetch 
operation 

,X<0 »8 » 1> 

specifies a fetch of the low-order eight bits of location X with signed exten- 
sion, upon evaluation produces the value -1, as in the example above, repre- 
sented in %BPVAL bits. In contrast, the fetch operation 

♦ Y < 1 8 1 > 

specifies a fetch of the low-order eight bits of location Y with unsigned exten- 
sion, which produces the value 255 in %BPVAL bits. 



3.2 Data Segments 



During the execution of a BLISS program, values are stored in data segments. 
A data segment consists of one or more addressable units of memory. In its 
simplest form, a data segment contains a single value. In its more complicated 
forms, a data segment can contain many values of various lengths. 
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The different kinds of data segments can be classified as follows: 

Data Segments 
Scalars 
Structures 
Predeclared Structures 
VECTOR Structures 
BITVECTOR Structures 
BLOCK Structures 
BLOCKVECTOR Structures 
Programmed Structures 

A scalar segment contains a single value, whereas a structure may contain any 
number of values. Each predeclared structure is a part of the definition of 
BLISS, and it is invoked by using one of the predeclared structure names 
(VECTOR, BITVECTOR, BLOCK, or BLOCKVECTOR) in the declaration 
of a data segment. A programmed structure is defined by the programmer and 
can be used to organize the contents of a data segment in any way. 

3.2.1 Addressable Units and Units per BLISS Value 

The three target-system families supported by BLISS differ in four respects 
having to do with their storage organization that affect the source -language 
syntax and semantics to some degree. These differences are as follows: 

1. Maximum (or only) "word" size, already described as the BLISS full- 
word consisting of %BPVAL bits. 

2. Smallest directly addressable unit of storage. 

3. Number of addressable units per BLISS value (i.e., per fullword). 

4. Size of an address value. 

The size of the smallest addressable unit, in bits, is given by the predeclared 
literal %BPUNIT (6its per unit.) Its value is 8 for both BLISS-16 and 
BLISS-32 — byte oriented target systems; and 36 for BLISS-36 — a word 
oriented target system. 

The number of addressable units per BLISS value is the quotient of %BPVAL 
over %BPUNIT. This value is given by the predeclared literal %UPVAL 
(imits per i>a/ue). Its value is 2 for BLISS-16 (two bytes per PDP-11 word), 4 
for BLISS-32 (four bytes per VAX-11 longword), and 1 for BLISS-36. 

The final difference is the number of bits required for a maximum address 
value, given by the predeclared literal %BPADDR. Its value is 16 for 
BLISS-16, 32 for BLISS-32, and 18 or 30 for BLISS-36, depending on the 
setting of the EXTEND module-switch. (This value is usually less significant 
than the others, as its utility is limited to certain kinds of operations on 
addresses that are not commonly required.) 

The literals just described are used in the subsequent discussions of data- 
segment types. 
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3.2.2 Scalars 

In BLISS-16 and BLISS-32, the storage occupied by a scalar segment de- 
pends on the allocation-unit that is associated with the segment. The alloca- 
tion-unit is given in the declaration of the name of the segment and is one of 
the following keywords: 

LONG (for 32 bits) <= BLISS-32 only 

WORD (for 16 bits) <= BLISS-16/32 only 
BYTE (for 8 bits) <= BLISS-16/32 only 

When no allocation-unit is given, WORD is assumed in BLISS-16 and LONG 
is assumed in BLISS-32. In BLISS-36, only fullword scalar segments can be 
allocated. 

The kind of extension used when the value of a data segment is fetched 
depends on the extension-attribute (BLISS-16/32 only) that is associated with 
the segment or the field-selector associated with the fetch operation. The 
extension-attribute is one of the following keywords: 

UNSIGNED (for unsigned extension) 
SIGNED (for signed extension) 

When no extension-attribute or field-selector is given, unsigned extension is 
assumed. 

The extension-attribute does not affect the amount of storage used for a data 
segment. Its only effect is on the way the value is extended to %BPVAL bits 
when it is fetched. It is valid to give an extension-attribute with a fullword 
data segment, but the attribute has no effect since the value is already 
%BPVAL bits long. 

An example of the declaration of a scalar segment is: 

OWN Xi 

This declaration describes a segment that is allocated permanently before 
execution begins (because it is OWN), that is named X, that is a scalar 
(because no structure-attribute is given), that occupies a fullword (because no 
allocation-unit is given), and that uses unsigned extension (because no exten- 
sion-attribute is given). 

The features of a data segment can be illustrated in a diagram. In the follow- 
ing, the declaration of X is given together with the diagram for the corre- 
sponding data segment: 

Declaration Diagram 

own x ; 2360 X / 15 / (%BPVAL) 

This diagram represents a data segment in a simple and abstract way; that is, 
it does not show the specific layout of the data in terms of the byte boundaries 
(where applicable), bit sequences, and addresses of storage. A more detailed 
notation is introduced in Chapter 11. 
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The diagram represents the data segment as follows: 

1. The address of the data segment is given in two forms. The first form is 
an (arbitrarily chosen) integer, 2360, used by the hardware to locate the 
segment. The second form is the name, X, that is used by the program 
to designate the segment. 

2. The storage is represented by a box followed by a parenthesized expres- 
sion. The expression shows how many bits of storage the box represents. 

3. The contents of the data segment is given as a literal, 15, written inside 
the box. It is this part of the diagram that changes as program execution 
proceeds. 

In this example, the value of X is 2360 (the address of the data segment), 
whereas the value of .X is 15 (the contents of the data segment). 

BLISS-16/32 ONLY 

The preceding example describes a scalar that occupies a fullword. Exam- 
ples of scalars that, in BLISS-16 or BLISS-32, occupy a word and a byte 
are: 

Declaration Diagram 

OWN Y: WORD! 1000 Y / 28 / (16) 

own z: byte; 2440 Z / 18 / (8) 

In these examples, each data segment has the UNSIGNED extension-at- 
tribute by default. Thus the values fetched from Y are in the range from 
to (2**16)-1 and the values fetched from Z are in the range from to 
(2**8)-l. 

An example of a scalar that has the SIGNED extension-attribute is: 

Declaration Diagram 

OWN R: SIGNED BYTES 3002 R Z Zi> / (8) 

The values fetched from R range from -(2**7) through (2**7)-l. Thus al- 
though R and Z (in the preceding paragraph) both occupy eight bits of 
storage, their values are interpreted differently when they are fetched. 

For the purposes of the following discussions, in BLISS-36 scalar data-seg- 
ment declarations can be thought of as having an implicit allocation-unit of 
%UPVAL value (i.e., one addressable unit per segment), and an implicit 
UNSIGNED extension attribute. 

3.2.3 VECTOR Structures 

A vector structure is a sequence of scalar elements. The number of elements is 
the extent of the vector, and is given as part of the declaration of the segment 
name. The elements are numbered, with for the first element, 1 for the 
second, and so on. 

Each element of a vector has the same allocation-unit and extension-attrib- 
ute. This information can be given as part of the declaration of the vector. If 
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the allocation-unit is not given, the default is the same as for scalar segments 
(fullword allocation). If the extension-attribute is not given, unsigned exten- 
sion is assumed (where applicable). 

An example of a vector is: 

Declaration Diagram 

own A: YECT0RC3]; 5440 A[0] / 28 / (%BPVAL) 

All] / 5 / (%BPVAL) 

A[2] / 133 / (%BPVAL) 

This declaration describes a segment that starts at address 5440 and is named 
A. The declaration gives the extent of the vector as 3 and so the vector has 
three elements. The declaration does not give an allocation-unit, so each 
element occupies a fullword. 

A particular element is selected by a bracketed subscript expression. Suppose 
that the contents of a data segment named IND is 3, and consider the contrast 
between the following expressions: 

Expression Value 

aC\ind-2] 5440+%UPVAL (the address of the second element) 
.ac.ind-23 5 (the contents of the second element) 

BLISS-16/32 ONLY 

An example of a declaration that gives both allocation-unit and extension- 
attribute is: 

Declaration Diagram 

OWN B: UECT0RC3 >W0RD ^SIGNED] 5 



B[0] I— 


15 


/ 


(16) 


B[l] L_ 


3 


/ 


(16) 


B[2] ZZ 


4 


/ 


(16) 



This declaration describes a segment that starts at address 46046 and is 
named B. It is similar to the segment named A, described in the preceding 
paragraph. However, the allocation-unit is given explicitly as WORD, and 
therefore each element of the vector occupies 16 bits. It follows that the 
vector occupies only six bytes of memory. Furthermore, the extension-at- 
tribute is given explicitly as SIGNED, and therefore, the fetched contents 
of an element of B is subject to signed extension. 

An example of a vector of bytes is: 



Declaration 


Diagram 








OWN C: VECTOR [4 »BYTE3 5 


221 C[0] ZZ 


7 


/ 


(8) 




C[l] I— 


7 


/ 


(8) 




C[2] L- 


2 


/ 


(8) 




C[3] 1— 


4 


/ 


(8) 
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This data segment is a vector of four elements and occupies four bytes of 
memory. Since an extention- attribute is not given, UNSIGNED is assumed 
by default. 

3.2.4 BITVECTOR Structures 

A bitvector structure is similar to a vector structure. However, bitvector struc- 
tures are designed especially to handle bit strings, and each element of a 
bitvector structure is a single bit. 

An example of a bitvector structure is: 

Declaration Diagram 

OWN STATUS: B I TUECTOR C 1 5 ] 5 1604 STATUS [0] L 1 / (1) 



STATUS[1] L 1 / (1) 

... (and so on, until) 



STATUS[14] L Q 7 (1) 

(not used) / ///// 7 (n) 

This declaration describes a segment that has 15 elements and thus makes use 
of 15 bits of memory. The number of unused bits, n, in the data segment 
allocated for this structure would be one in BLISS-16 and BLISS-32 (byte 
allocation), and 21 in BLISS-36. 

A bitvector starts at the low-order (rightmost) bit of its first addressable unit 
of storage. Thus in BLISS-16 or BLISS-32, STATUS[0] designates the low- 
order bit of the byte whose address is 1604, STATUS [7] designates the high- 
order bit of that byte, STATUS [8] designates the low-order bit of byte 1605, 
and so on. 

In BLISS-36, where the structure is entirely contained in one word, the refer- 
ences STATUS [0] and STATUS [8] designate the low-order bit and the ninth 
bit "from the right", respectively, of word 1604. (Note that bit-position 
numbering in BLISS is consistent across dialects: bit numbers increase from 
low order to high order, "right to left", regardless of the target-system hard- 
ware convention.) 

Neither an allocation-unit nor an extension-attribute can be used with 
BITVECTOR. (The number of addressable units allocated is the smallest 
number of units that can accomodate the given number of bits.) When the 
contents of an element of a bit vector is fetched, unsigned extension is always 
used. 

3.2.5 BLOCK Structures 

A block structure is a sequence of components. The block as a whole has a 
name, which is declared using the BLOCK structure-attribute. In addition, 
each component of a block has its own name. 
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A block is declared with a size and, in BLISS-16 and BLISS-32, an alloca- 
tion-unit. The size specifies the amount of storage required for the entire 
block. The allocation-unit determines the units in which the size is measured. 
The default allocation-unit is the same as for a scalar segment declaration 
(fullword allocation). 

The individual components of a block can have different sizes. The way in 
which the size of each component is specified is given in Chapter 11. For 
purposes of the present discussion, it is sufficient to state that the size is 
determined when the program is written and cannot change during program 
execution. 

Observe that a block differs from a vector in two ways. A block is less flexible 
than a vector because, in normal usage, the name of a block component is 
given explicitly when the program is written, whereas the subscript of a vector 
element can be calculated during program execution. On the other hand, a 
block is more flexible than a vector because the components of a block can 
have various sizes, whereas the elements of a vector must all have the same 
size. 

An example of a BLOCK structure, using BLISS-32, is: 

Declaration Diagram 



OWN ITEMs BLOCK [ITEMS I ZE »BYTE] 5 33300 ITEM[FLG] L / ( 2) 

ITEM[N1] / 235 / (14) 

ITEM[LOC] / 17 / (32) 

This declaration describes a segment that starts at address 33300 and is 
named ITEM. The declaration gives the size of the block as ITEMSIZE. The 
diagram shows that the individual components are FLG (two bits), Nl (four- 
teen bits), and LOC (32 bits). Since ITEMSIZE must be the total number of 
bytes used, the diagram implies that the value of ITEMSIZE should be 6. 

The address of a component of the block is written exactly as it appears in the 
diagram. Consider the contrast between the following expressions: 



Expression 


Value 


ITEMCLOC] 


33302 


♦ ITEMCLOC] 


17 



(the address of the third component) 
(the contents of the third component) 

3.2.6 BLOCKVECTOR Structures 

A blockvector structure is a sequence of elements (as is a vector structure), 
but each element consists of a block. The number of elements is the extent of 
the blockvector, and is given as part of the declaration of the segment name. 
The elements are numbered, with for the first element, 1 for the second, and 
so on. 

Each element of a blockvector is a sequence of components (as is a block). 
Each component is a scalar and has its own name. Therefore, the combination 
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of the blockvector name, the subscript of an element, and the name of a 
component is used to designate a single value. 

In addition to the extent, an element-size and, if BLISS-16 or BLISS-32, an 
allocation-unit are given in the declaration of a blockvector. The element-size 
specifies the amount of storage for each element (i.e., the block size), and the 
aHocation-unit determines the units in which the element-size is measured. 
The default allocation-unit is the same as for a scalar segment (fullword 
allocation) . The storage required for a blockvector is the product of its extent 
and its element-size. 

An example of a BLOCKVECTOR structure, using BLISS-36, is: 

Declaration Diagram 

OWN 0: BL0CKVECT0RC2 »0S] i 6C 



Q[0,FLAG] / 


5 


/ 


(8) 


Q[0,VAL] Z_ 


62 


/ 


(28) 


Q[0,PTR] L. 





/ 


(36) 


Q[1,FLAG] / 


25 


/ 


(8) 


Q[1,VAL] Z_ 


78 


/ 


(28) 


Q[1,PTR] L_ 


23 


/ 


(36) 



The declaration of Q gives the extent as 2 and the element size as QS. Accord- 
ing to the diagram, each element has three components, FLAG, VAL, and 
PTR. Since QS must be the total number of fullwords used by each element, 
the diagram implies that the value of QS should be 2. 

Suppose that the contents of a data segment named I is 0, and consider the 
contrast between the following expressions: 



Expressions 


Value 




QC . 1 + 1 fFLAG] 


6002 


(address of component) 


♦Q[ . 1+1 >FLAG] 


25 


(contents of component) 



3.2.7 Programmed Structures 

The predeclared structures discussed in the preceding sections provide the 
data structures usually required for system programming. To provide for other 
data structures, BLISS has a feature, the STRUCTURE declaration, that 
permits a programmer to design and use his own data structures. This feature 
of BLISS is described in Chapter 11 where, in addition, each predeclared 
structure is defined in terms of a STRUCTURE declaration. 



3.3 Character Sequence Data 



The representation of character data differs among the three BLISS dialects 
due to basic architectural differences. Character data is represented in a very 
different way in BLISS-36 target systems than in BLISS-16 and BLISS-32 
target systems. In spite of this difference, it is possible to think about charac- 
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ter data in a single, uniform way that applies to all BLISS target systems and, 
more importantly, to code BLISS programs that behave the same way and 
give the same results on all $LISS systems, even though the results are 
achieved in significantly different ways at object level. 

The BLISS features for handling character data in this common (i.e., trans- 
portable) way involve some new terminology and a set of special character- 
handling functions; these features are described in detail in Chapter 20. 

The representation of character data and, in particular, sequences of charac- 
ters is described here in two ways. First, character sequences are described in 
a general way that includes only the aspects that are common to all BLISS 
target systems. Second, the representation of character sequences is described 
specifically for each BLISS target system. 

3.3.1 General Character Representation 

Loosely speaking, a character sequence is like a vector of character data 
elements. This analogy may be useful in understanding the following descrip- 
tion of BLISS character sequences. (Fuller detail is given in Chapter 20.) 

A character code is a sequence of bits that represents a character. Usually the 
ASCII encoding of characters is used in BLISS. 

A character position is the storage for a single character code. For a given 
implementation of BLISS, the size of a character position is determined by 
two factors: the requirements of the character code and the organization of 
storage. 

A character position sequence is a portion of storage that is used for one or 
more character positions. Such a sequence has a first and last position. For 
each position except the first, there is a previous position, and for each posi- 
tion except the last, there is a next position. 

A character data segment is a character position sequence that is allocated as 
a single portion of storage. In the simpler applications of character handling, 
it is possible to treat each character data segment as a separate unit, contain- 
ing a complete character position sequence and allocated in the same way as 
other data segments. 

A character pointer is a value that designates a character position. Sometimes 
a character pointer is set to the first character position of a sequence and 
remains there, providing access to the entire sequence. In other cases, a char- 
acter pointer is used to scan back and forth in a sequence, selecting one 
position after another. A character pointer can be correctly interpreted only 
by a character handling function. It occupies a full word. 

The length of a character position sequence is the number of character posi- 
tions in the sequence. The length of a sequence is not included as part of the 
sequence itself. In order to fully specify a character position sequence, both its 
length and a pointer to its first position must be given. Typically, the parame- 
ters of the character handling functions occur in pairs, a length followed by a 
pointer. 
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3.3.2 Character Sequence Operations 

The basic operations of character handling are the allocation of storage, crea- 
tion of a pointer, moving of a pointer, fetching or storing of a character code, 
and the comparison of character sequences. All of these operations must be 
performed by means of the specific character handling functions provided for 
this purpose. For example, the contents of a character position must always 
be fetched or stored by means of a character pointer that designates the 
character position. In contrast, a character pointer can be fetched or stored 
like any other fullword value (by means of the fetch-operator, ".", or the 
assignment operator, "="). 

Returning to the analogy with a vector of character data elements, the follow- 
ing correspondences can be established: 

• A character code corresponds to the contents of an element of the vector. 

• A character position corresponds to the storage for an element of the 
vector. 

• A character position sequence corresponds to a contiguous sequence of 
elements of a vector (possibly but not necessarily the entire vector). 

• A character data segment is the complete vector. 

• A character pointer corresponds to the address of an element of the 
vector. 

The ways in which this analogy is inexact are: 

• A character position need not correspond to an addressable unit of 
storage. 

• A character pointer is not simply an address value. 

(These considerations apply specifically to BLISS-36 as will be seen below.) 

3.3.3 BLISS-16 Character Representation 

In BLISS-16 there are two character positions per fullword. Characters are 
allocated in storage with the leftmost character of the source string in the low- 
order (or ''rightmost") character position of the first or only fullword. Addi- 
tional fullwords or bytes are allocated in ascending address order. For exam- 
ple, the source character string 'ABCDEFGH' would be allocated as follows: 

Diagram 



7000 


/BA/ 


(16) 


7002 


/DC/ 


(16) 


7004 


/FE/ 


(16) 


7006 


/HG/ 


(16) 



Note that the eight-character string 'ABCDEFGH' can only appear in the 
context of a PLIT (a type of primary expression) since a string literal itself, as 
a primary expression, cannot exceed the capacity of a fullword: two character 
positions in BLISS-16. (See Chapter 4, "Primary Expressions".) 
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The BLISS-16 representation is related to the general BLISS representation 
of character sequences as follows: 

• A character code consists of 8 bits. 



• 



• 



• 



A character position is a byte of storage. 

A character position sequence is a contiguous sequence of bytes of storage 
with successive characters, considered from left to right, contained in 
successive bytes from lower to higher addresses. 

A character data segment is also a contiguous sequence of bytes of stor- 
age. 

A character pointer is the address of a byte. 



3.3.4 BLISS-32 Character Representation 

In BLISS-32 there are four character positions per fullword. Characters are 
allocated in storage with the leftmost character of the source string in the 
low-order (or "rightmost") character position of the first or only fullword. 
Additional fullwords or bytes are allocated in ascending address order. For 
example, the source character string 'ABCDEFGH' would be allocated as 
follows: 

Diagram 

36014 /DCBA/ (32) 

36018 /HGFE/ (32) 

Note that the eight-character string 'ABCDEFGH' can only appear in the 
context of a PLIT (a type of primary expression) since a string literal itself, as 
a primary expression, cannot exceed the capacity of a fullword: four character 
positions in BLISS-32. (See Chapter 4, "Primary Expressions".) 

The BLISS-32 representation is related to the general BLISS representation 
in the same way as in BLISS-16. 

3.3.5 BLISS-36 Character Representation 

In BLISS-36 there are five ASCII character positions per fullword or six 
SIXBIT character positions. Characters are allocated in storage with the left- 
most character of the source string in the high-order (or "leftmost") character 
position of the first or only fullword. Additional fullwords are allocated in 
ascending address order. For example, the ASCII string 'ABCDEFGH' would 
be allocated as follows: 

Diagram 

21005 /ABCDE/ (36) 

21006 /FGH / (36) 

Note that the eight-character string 'ABCDEFGH' can only appear in the 
context of a PLIT (a type of primary expression) since a string literal itself, as 
a primary expression, cannot exceed the capacity of a fullword: five character 
positions in BLISS-36. (See Chapter 4, "Primary Expressions".) 
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The BLISS-36 representation is related to the general BLISS representation 
of character sequences as follows: 

• A character code consists of 7 bits. 

• A character position is a 7-bit field of a 36-bit word of memory. 

• A character position sequence is a contiguous sequence of character posi- 
tions with successive character codes, considered from left to right, con- 
tained in adjacent 7-bit fields beginning at any of the five character 
positions in a word and continuing toward positions in the lower order 
part of the word and then to the high order 7 bits of the next word, and 
so on. 

• A character data segment is a contiguous sequence of 36-bit words. 

• A character pointer is a special 36-bit value that consists of both address 
and position and size information describing the character position. 

(In DECsystem-10 terminology, a character pointer is a byte pointer 
that, when used as the operand of an ILDB (increment and load byte) 
instruction, will fetch the character code value from the indicated charac- 
ter position.) 



3.4 Storage Organization 



During the execution of a BLISS-compiled object program, storage consists of 
the following: 

Storage 
Storage for the given program 
The Stack 
The Registers 

Storage for the First Module 
Storage for the Second Module 

Storage for the Last Module 
Other Storage 

The other storage includes the routines and data of the operating system, the 
run-time routines for BLISS, and the storage for programs other than the 
given program. 

The stack, the registers, and the storage for each module are described in the 
following sections. 

3.4.1 The Stack 

The stack is used to store temporary data associated with the execution of the 
routines in a BLISS program. The stack is composed of frames. Upon entry to 
a routine, a frame is pushed on the stack for use in executing that routine. 
Upon return from the routine, the frame is popped from the stack. 
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A stack frame contains data segments of two kinds. Some of the data seg- 
ments are declared as LOCAL or STACKLOCAL. Such segments are directly 
accessible from the program and are used for values that are needed only 
during the execution of the routine in which they are declared. The other data 
segments are allocated by the compiler and are not accessible from the pro- 
gram. These segments are used for such values as the return address of the 
routine or the intermediate results that are produced during the evaluation of 
an expression. 

The declaration of LOCAL and STACKLOCAL names is described in Chap- 
ter 10. The relation between a routine and the stack is further described in 
Chapter 12. 

3.4.2 The Registers 

The registers of BLISS correspond to the general registers of the target-system 
hardware. Each register contains one fullword value. Each of the registers is 
considered to be a single data segment. 

The use of registers is normally determined by the compiler, not the program. 
Access to a register uses less time than access to ordinary storage; therefore, 
registers are often used to store the intermediate results and addressing in- 
dices of a calculation. Under special circumstances, registers can be accessed 
by the program. 

The declaration of register names is described in Section 10.7. 

3.4.3 Storage for a Program Module 

A module uses four kinds of program sections. Each kind of program section 
has a special purpose, as follows: 

• An OWN program section contains a data segment for each name that is 
declared OWN in the module. Such a data segment is permanently allo- 
cated. It can be accessed only from the module in which it is declared. 

• A GLOBAL program section contains a data segment for each name that 
is declared GLOBAL in the module. Such a data segment is permanently 
allocated. It can be accessed from the module in which it is declared and 
in any module in which its name is declared EXTERNAL. 

• A PLIT program section contains a data segment for each PLIT used in 
the module. 

• A CODE program section contains a code segment for each routine that is 
declared in the module. 

The programmer can leave the management of program sections to the com- 
piler; and in that case each module will have no more than one of each kind of 
program section. On the other hand, the programmer can specify several 
program sections of the same kind for a module and can determine which data 
segments or routines are allocated in which program sections. 
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The division of storage for a module into sections permits the operating sys- 
tem to manage storage effectively. For example, an OWN section need be 
present only when its associated module is being executed, whereas a 
GLOBAL section must be present more frequently. For another example, the 
PLIT and CODE sections are not modified during program execution and can 
therefore be regarded as read-only storage. 

The declarations of OWN and GLOBAL segment names are described in 
Sections 10.1 and 10.2. The definition of plits is given in Section 4.4. The 
declaration of routines is described in section 12.3. 
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Chapter 4 

Primary Expressions 



In most high level languages, the term expression refers to the kinds of con- 
struct that perform calculation, such as the addition of two numbers or, 
perhaps, the concatenation of two strings. Such expressions obviously have 
values; in fact, their sole purpose is to calculate values. 

In BLISS, the term expression applies to all constructs of the language except 
declarations. For example, the construct that assigns a value to a data seg- 
ment is an expression and has a value. As another example, the construct that 
controls an execution loop is also an expression and has a value. Thus it is 
possible, although unusual, to add the value of an assignment-expression to 
the value of a loop-expression. 

There are four kinds of expression, as shown in the following syntax diagram: 



expression 


/ primary \ 
1 operator-expression 1 
| executable-function I 
v control-expression J 



This chapter describes primary expressions. It is the first of four chapters that 
describe the various kinds of expressions. 

The first section of this chapter discusses primaries in a general way. Each of 
the remaining sections of this chapter describes one kind of primary in more 
detail. 



4.1 Primaries 



Every expression is built up from one or more primaries. The simplest form of 
expression is a single primary. More complicated expressions are constructed 
of primaries in combination with operators. 

There is considerable variety among the primaries. A primary can be simply a 
numeric-literal, such as 4, or it can be a block of considerable length and 
complexity. A primary can specify a very elementary operation, such as the 
formation of a storage address, or it can call a long and complicated routine. 
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Examples of primary expressions are: 

5 A numeric-literal whose value is 5 

'Enter data:' A string-literal composed of 11 ASCII characters 

plit (5»4> A pointer to a pair of literals 

top_of_list A name 

f ( ) A call to routine F with no parameters 

G(5t plit (5 »4) > A call to routine G with two parameters 

xeaccess-LEVel] A structure-reference to a field of a data structure 
named X 



BETA<2 f6> 

( , X + . Y ) 

BEGIN 
LOCAL T5 
T = 5 
G(T ,5) ; 
END 



A field -reference to the six high-order bits of the byte 
at BETA 

A simple kind of block, called a parenthesized expres- 
sion 



A more complicated block, which contains declaration 
and two expressions 



4.1.1 Syntax 



primary 


/ numeric-literal \ 
I string-literal ) 
1 Plit I 
1 name f 
< block > 
J structure-reference | 
I routine-call 1 
I field-reference | 
V codecomment / 



4.1.2 Semantics 

The semantics of primaries is given in the following sections, where each kind 
of primary is considered individually. 



4.2 Numeric-Literals 



A numeric-literal is used to represent a specific number. An integer value can 
be written in any one of four radices: binary, octal, decimal, or hexadecimal. 
A special-purpose way of representing an integer is the character-code literal, 
which represents the ASCII code for a given character as a transportable, 
full word value. A floating-point value can be written in single or double preci- 
sion. 
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Wherever the radix for a BLISS literal is not given, the radix is assumed to be 
decimal. This manual follows the same convention; that is, wherever a num- 
ber appears in the text without an explicit radix, the number is assumed to be 
decimal. 

The following examples show five different ways to write a numeric literal for 
the value 15. 



15 

7,3 '1111' 

10' 17' 

'JCDECIMAL 

IX 'F ' 



15 



Standard decimal-literal 
Binary integer-literal 
Octal integer-literal 
Decimal integer-literal 
Hexadecimal integer-literal 



The character-code-literal is used to express, in a transportable way, the 
numeric value of the ASCII code for a character. For example, 

IC 'A ' 

has the value 65 (decimal), which is the ASCII code for "A". 

Certain literal names are predeclared by the compilers and have specific 
numeric values. The values reflect various aspects of the target system archi- 
tecture. For example, r rBPADDR is predeclared with a value that is the 
number of bits required for an address value, which varies for each target 
system. Therefore the predeclared name f V BPADDR has a different value for 
each BLISS compiler: 16 in BLISS-16, 32 in BLISS-32, and 18 or 30 (depend- 
ing on the target-system environment) in BLISS-36. The predeclared literal 
names are described in Section 14.1.5. 



4.2.1 Syntax 





/ decimal-literal \ 


numeric-literal 


1 integer-literal I 
| character-code-literal f 




\ float-literal / 



decimal-literal 


decimal-digit ... 


decimal-digit 


J0I1I2I3I4I5I6I7I8I9J 



integer-literal 


(%B ) 

) %0 ( 

) %DECIMAL ( ' opt-sign integer-digit ... 

( %X ) 


opt-sign 


{ + 1 - 1 nothing } 
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integer-digit 



I 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 
A I Bl CI Dl El F 



character-code- 
literal 


C (C ' quoted-character 


quoted-character 


/ printing-character-except-apostrophe \ 
1 blank 1 
j tab I 



float-literal 


/ single-precision-float-literal \ 
I double-precision-float-literal I 
) extended-exponent-double-precision- C 
\ float-literal / 
/ extended-exponent-extended-precision- 1 
\ float-literal / 


single-precision- 
float-literal 


%E ' mantissa ( E exponent ) , 
( nothing J 


double-precision- 
float-literal 


< rD ' mantissa f D exponent ) , 
I nothing J 


extended-exponent- 
double-precision- 
float-literal 


{ G exponent \ <= 36 Only 
f ' f G ' mantissa ) Q exponent > ' <= 32 Only 
( nothing ) ' <= 32/36 


extended-exponent- 
extended-precision- 
float-literal 


^' mantissa j j^ ) ■ <= 32 Only 


mantissa 


• digits \ 

opt-sign ) d ^ its • i 
1 ■ digits 1 

V digits . digits / 


exponent 


opt-sign digits 


digits 


decimal-digit ... 


opt-sign 


j + 1 - 1 nothing | 
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Some of the numeric-literals are composed of two lexemes. Specifically, in an 
integer-literal, the radix indicator ( f VB, r ( 0, ^DECIMAL, or ^X) is a lexeme 
and the remainder is another; and in a float-literal, the precision indicator 
( r rE, M), f '(G or r ( H) is a lexeme and the remainder is another. 

The quoted-string in a numeric-literal can be supplied by certain lexical- 
functions (see Section 15.5). 

A printing-character is any ASCII character whose code, i, is in the range 33 < 
i < 126 (decimal). A printing-character-except-apostrophe is any printing 
character except an apostrophe. The apostrophe is the ASCII character with 
code 39 (decimal). 

The blank is the ASCII character with code 32 (decimal). The tab is the 
ASCII character with code 9 (decimal). 

4.2.2 Restrictions 

The digits in an integer-literal must conform to the radix specified by the 
keyword at the beginning of the literal. Depending on whether the keyword is 
f VB, r rO, c ( DECIMAL, or ( cX, the digits must be binary, octal, decimal, or 
hexadecimal. 

A space must not appear in a numeric-literal except between the lexemes of a 
two-lexeme numeric-literal (see Section 4.2.1). 

When a numeric-literal (other than a float-literal) is evaluated, its value, i, 
must fit in a fullword; that is, it must lie in the range 

-(2**('7BPVAL-1)) < i < (2**(%BPVAL-1))-1 

See Section 3.1.1 for the definition of %BPVAL for each target system. 

When a float-literal is evaluated its value, x, must fit in the target system 1 ? 
machine representation of a floating-point value. The maximum approximate 
value range of x for each target-system family is as follows: 



For BLISS-16 
For BLISS-32 
For BLISS-36 



0.29*(10**-38) < abs(x) < 1.7*(10**38) 
0.84*(10**-4932) < abs(x) < 0.59(10**4932) 
0.56*(10**-308) < abs(x) < 0.9*(10**308) 



The listed value ranges of x reflect %D for BLISS-16, %H for BLISS-32, and 
f VG for BLISS-36. 

Depending on the compiler used, float-literals can produce values that occupy 
up to four fullwords; therefore, float-literals producing values that occupy 
more than one fullword must appear in either a plit (see Section 4.4) or an 
initial-attribute (see Section 9.6). 
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The relationship, by compiler, of float-literals to full words is: 



7 loat-literal 


Size (fullwords) 


keyword 


32 


36 16 


( <E 


1 


1 2 


r , D 


2 


2 4 


( <G 


2 


2 


f VH 


4 


— — 



4.2.3 Defaults 

The default for the sign of a numeric-literal is ' + '. For example, the numeric- 
literal SO '777' is equivalent to f r()' + 777'. 

The default radix is decimal; that is, when a sequence of digits appears 
without a radix keyword and without quotes, it is assumed to be a decimal- 
literal. 



4.2.4 Semantics 

A decimal-literal is interpreted as the decimal representation of an integer 
value. 

An integer-literal begins with a keyword that determines its interpretation by 
giving the radix of the literal. Depending on whether the keyword is f VB, f VO, 
'(DECIMAL, or r rX, the sequence of digits within the quotes are interpreted 
as a binary, octal, decimal, or hexadecimal representation, respectively, of an 
integer value. 

The value of a character-code-literal is the integer that is the ASCII character 
code for the quoted-character. When two apostrophes are used as the quoted- 
character, the value of the literal is the character code for a single apostrophe; 
that is, the character-code-literal f VC has the value 39 (decimal). 

The evaluation of a numeric-literal produces an integer value. If the literal 
has a minus sign, then its value is represented as a negative number in two's 
complement form. The evaluation of a f VE float-literal in 32 and 36 produces a 
dialect-specific fullword value. 



4.2.4.1 Limitations on Float-Literals — Referring to the chart in Section 4.2.2, 
which defines the float-literal sizes (in fullwords) needed by the compiler, 
note that values requiring more than C 7BPVAL bits for their representation 
cannot be stored in a fullword and cannot be directly operated upon by any of 
the BLISS operators or executable-functions. 

Except for a few builtin machine-specific-functions, BLISS does not provide 
facilities for operating upon any float -literal as such. Float-literals are pro- 
vided in BLISS in order to facilitate the development of special data segments 
and special routines for performing high-precision arithmetic. 
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4.3 String Literals 



A string-literal contains a sequence of ASCII characters. The value of the 
string-literal is obtained by encoding the sequence of characters in one of 
several different ways, depending on the string-type of the literal (e.g., 
%ASCII, ScASCIZ, %RAD50_11, %P). 

A string-literal whose value occupies one fullword or less can be used as a 
primary, that is, can appear anywhere that a primary expression is allowed. 
The number of characters that can be encoded in a fullword varies with both 
the target system and the string-type (Section 4.3.2). Examples are: 

n any dialect 

n BLISS-32 or BLISS-36 

n BLISS-16 or BLISS-32 

n BLISS-32 only 

n BLISS-36 only 

In each of these examples, the quoted string is encoded into one fullword or 
less in each of the dialects specified. 

A string-literal whose value occupies more than a fullword is not a primary 
expression and can be used only within a plit expression (see Section 4.4) or in 
an initial-attribute (see Section 9.6). An example is: 

'A complete list of errors follows:' 

The encoded value of this string-literal, consisting of 34 character positions, 
occupies much more than a fullword on any target system. 



'X.ASCI I 


'AB ' i 


7.ASCI I 


'ABCD' i 


/f.RADBO. 


.11 'ABC ' i 


■JT.RAD50. 


.1 1 'ABCDEF ' i 


7.RAD50. 


-10'ABCDEF' i 
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4.3.1 Syntax 



string-literal 


( string-type ) quote d-string 
( nothing J 


string-type 


/%ASCII \ 
I %ASCIZ I 
1%ASCIC J <= 16/32 
J °/< ASCID I 
\%RAD50_11 ( <= 16/32 
1 %RAD50_10 1 <= 36 Only 
1 %SIXBIT I <= 36 Only 
\%P / <= 16/32 


quoted-string 


' ( quoted-character ... ) 
( nothing J 


quoted-character 


/ printing-character-except-apostrophe \ 
1 blank 1 
j tab 1 



A printing character is any ASCII character whose code, i, is in the range 33 < 
i < 126 (decimal). A printing-character-except-apostrophe is any printing 
character except an apostrophe. The apostrophe is the ASCII character with 
code 39 (decimal). 

The blank is the ASCII character with code 32 (decimal). The tab is the 
ASCII character with code 9 (decimal). 

Some of the string-literals are composed of two lexemes, the string-type and a 
quoted-string. Spaces are permitted between the two lexemes. 

The quoted-string in a string-literal can be constructed by certain lexical- 
functions, which are described in Chapter 15. A quoted-string constructed in 
that way can be composed of any sequence of ASCII characters and therefore 
is not restricted to printing characters, blanks, and tabs. 

The quoted-string in a string-literal can also be supplied by another string- 
literal. This feature is mainly useful in the design of macros and is discussed 
in Section 15.3.2.2. 

4.3.2 Restrictions 

A quoted-string is a single lexeme. As the syntax shows, the quoted-string can 
contain blanks and tabs. These characters are interpreted as characters in the 
string, not as characters that divide the quoted-string into several lexemes. 
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BLISS-16 


2 


1 


BLISS-32 


4 


3 


BLISS-36 


5 


4 



Aside from blanks and tabs, no other spaces (as defined in Section 2.2.2) can 
appear in the source text for a quoted-string. 

A string-literal that is not a plit-string in a plit or initial-attribute must fit in 
one fullword. With %ASCID excepted, specific limitations on string length are 
given in the following table, by dialect and string-type: 

Dialect Max. Number of Characters in Fullword 

ASCII ASCIZ ASCIC RAD50_11 SIXBIT RAD50_10 P 

13 — — 3* 

3 6 — — 7* 

— — 6 6 — 

* Plus optional sign character. 

BLISS-16/32 ONLY 

A % ASCIC string-literal must contain no more than 255 quoted-characters. 

A %RAD50 11 string-literal may contain only the characters A through Z, 

through 9, blank, period (.), and dollar ($) in the quoted-string. Lowercase 
letters appearing in the quoted-string are encoded as the corresponding 
uppercase letters. 

A %P string-literal must contain only the decimal digits (0 through 9) 
except for an optional initial sign (+ or -). There must not be more than 31 
digits in the quoted-string. 

BLISS-36 ONLY 

A %RAD50 10 string-literal may contain only the characters A through Z, 

through 9, blank, period (.), dollar ($), and percent (%) in the quoted- 
string. Lowercase letters appearing in the quoted-string are encoded as the 
corresponding uppercase letters. 

A %SIXBIT string-literal may contain any quoted-characters except the 
following: tab (9), * (96), { (123), I (124), j (125), and ~ (126). (The paren- 
thesized ASCII codes are in decimal.) Lowercase letters appearing in the 
quoted-string are encoded as the corresponding uppercase letters. 

Other restrictions on the length of string-literals (if any) are given in the 
appropriate BLISS user's guide. 

4.3.3 Defaults 

The default for the string-type is %ASCII. For example, the string-literal 
'abc' is equivalent to %ASCII / abc'. 

The default for the sign in a %P string-literal is "+". For example, the string- 
literal %P '2 ' is equivalent to %P ' +2 ' . 
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4.3.4 Semantics 

Each quoted-character in a string-literal represents one character code in the 
value. A printing-character-exeept -apostrophe, a blank, or a tab represents 
itself. A sequence of two apostrophes represents a single apostrophe. 

A S ASCII) string-type is similar to a S ASCII type; however, 'r ASCII) differs 
in that it creates a string descriptor for the quoted-string, and expands to the 
address of the data segment that contains the descriptor. The string and its 
descriptor are allocated in a PUT PSECT (see Chapter 18), and just as the 
value of a PUT is the address of the plit-body. the value of ' < 'ASCII) is the 
address of the descriptor. 

The 'VASCID string creates the following descriptor formats: 

For BLISS-32: 



31 


24 


23 16 


15 





1 


14 


string length 


character pointer 



Note that onlv the BLISS-32 implementation of r ( ASCII) is compatible with 
XPORT strings. 

For BLISS-36: 



35 



18 17 



character pointer 



string length 



For BLISS-16: 



15 



string length 



character pointer 



This format follows the PDP-11 Extended Instruction Set guidelines. Note 
that the "string length" must be an unsigned 16- bit quantity in the range to 
65535 decimal. 

The remaining semantic description uses the generalized terms character 
position and character position sequence. The machine specific equivalents of 
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these terms are given in Section 3.3. (See also Chapter 20, on "Character 
Handling Functions".) 

The value of a string-literal is determined in several steps, as follows: 

1. For string-types %ASCIZ and %ASCIC, augment the string of quoted- 
characters as follows: 

a. If %ASCIZ, add a trailing null character (ASCII code 0) to the 
string. 

b. If %ASCIC (16/32 only), count the characters in the quoted-string 
and use this (8-bit integer) count as the initial 'character' of the 
string, preceding the first quoted-character. 

2. Encode the character string, augmented as required by Step 1, accord- 
ing to the string- type and dialect, as follows: 

a. For string types %ASCII, %ASCID, and %ASCIZ, form a charac- 
ter position sequence that has one character position for each 
character in the string. For BLISS-16 and -32, use the 8-bit ASCII 
code of the i'th character as the value of the i'th character posi- 
tion. For BLISS-36, use the corresponding 7-bit ASCII code. For 
rules governing the filling of the last unit of storage refer to Sec- 
tion 4.4.4. 

b. For string-type %ASCIC (16/32 only), form a character position 
sequence as in Step 2. a, but use the initial count 'character' value 
as is for the first character position. 

c. For string- type %RAD50 11 (16/32 only), extend the original 

quoted-string with enough trailing blank characters to make up a 
multiple of three characters, if necessary. Then use Radix-50 en- 
coding to form a character position sequence that has two charac- 
ter positions for each group of three characters in the string. If 
necessary, extend the resulting character position sequence with 
enough trailing, zero-valued positions to fill the final (or only) 
fullword occupied by the sequence. 

d. For string- type %RAD50 10 (36 only), use Radix-50 encoding to 

form a fullword for each group of six (or fewer) quoted-characters 
in the string. This encoding always produces one or more complete 
fullwords. 

e. For string type %SIXBIT (36 only), form a character position 
sequence that has one (6-bit) character position for each character 
in the string. Use the SIXBIT code equivalent of the ASCII code 
of the i'th character as the value of the i'th character position. If 
necessary, extend the resulting character position sequence with 
enough trailing, zero-valued positions to fill the final (or only) 
fullword occupied by the sequence. 
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4.4 Plits 



f. For string-type %P (16/32 only), use the PDP-ll/VAX-11 packed 
decimal string encoding to form a sequence that has one byte for 
each two digits of the quoted-string, and that provides a position 
for the sign in the last byte. Leading zero characters are not dis- 
carded in forming this sequence. (The packed decimal encoding is 
described in the VAX- 11/780 Architecture Handbook, Section 
4.11.) 

Note: The ordering of character positions in storage is system depen- 
dent, and is described in Chapter 3. The ASCII, Radix-50, and 
SIXBIT string encodings are described in Appendix B. 

3. Use the character position sequence obtained in Step 2 as follows: 

a. If the given literal appears in a plit or initial-attribute, use the 
sequence as the value of the literal. 

b. If the given literal does not appear in a plit or initial-attribute and 
the sequence is contained in a single fullword, the fullword is the 
required literal value. 

c. Otherwise, the sequence is invalid as a string-literal and the literal 
value is undefined. 

The interpretation of a string-literal is performed entirely by the compiler. If 
the string-literal is a plit-string, then the compiler uses the value in forming a 
literal in PLIT storage, as described in Section 4.4. If the string -literal is an 
initial-value, then the compiler uses the value to initialize the contents of a 
data segment, as described in Section 9.6. Otherwise, the compiler incorpo- 
rates the value of the string-literal in the object code it is generating. 



A constant value that requires no more than a fullword of storage can be 
represented by a numeric-literal or string-literal that stands alone (that is, is 
not contained in a plit) . A constant value that requires more storage must be 
represented by a plit. 

The value of a plit is not the value of the given constant but rather the address 
of a data segment that contains the given constant. The data segment for a 
plit is allocated in a PLIT program section, and it is initialized to the given 
constant value before program execution begins. 

There are two kinds of plits. The counted plit begins with the keyword PLIT, 
which stands for "pointer to literal". The data segment for this kind of plit 
begins with an extra fullword that contains the count for the plit. The count is 
the number of fullwords in the plit excluding the fullword used for the count. 
The second kind of plit, the uncounted plit, begins with the keyword UPLIT, 
which stands for "uncounted pointer to literal". The data segment for this 
kind of plit does not include a fullword for the count. 
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4.4.1 Syntax 



plit 


( PLIT ) 
\ UPLIT J 

/ allocation-unit \ <= 16/32 
1 psect-allocation 1 
| psect-allocation allocation-unit ■ <= 16/32 
n nothing J 

( plit-item ,... ) 


psect-allocation 


PSECT (psect-name) 


psect-name 


name 


plit-item 


{ plit-group \ 
< plit-expression > 
V plit-string ) 


plit-group 


i allocation-unit \ <= 16/32 

\ REP replicator OF > 

( REP replicator OF allocation-unit J <= 16/32 

( plit-item ,... ) 


16/32 Only => 
allocation-unit 


( LONG ) <= 32 Only 
I WORD > 
( BYTE ) 


replicator 


compile-time-constant-expression 


plit-expression 


link-time-constant-expression 


plit-string 


string-literal 



4.4.2 Restrictions 

An appropriate psect-declaration (see Section 18.1) must be made before a 
psect-allocation attribute (see Section 9.8) can be used in a plit. 

The value of a replicator must not be less than zero. 
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BLISS-16/32 ONLY 

The value of a plit-expression allocated as BYTE must lie in the range 
-(2**7) through (2**8)-l. The value of a plit-expression allocated as 
WORD must lie in the range -(2**15) through (2**16)-1. 

4.4.3 Defaults 

When no "REP replicator OF" construct is given, a replicator value of 1 is 
assumed. 



4.4.4 Semantics 

A plit causes constant data to be allocated. The value of the plit is the address 
of the first addressable unit of the data specified by the plit-items. The com- 
piler determines an address offset for the plit and the linker binds this offset 
to an absolute address. 

If the plit has the keyword PLIT and therefore is a counted plit, then the 
count is located in the fullword preceding the data specified by the plit-items. 
The count indicates the number of fullwords occupied by the plit data. 

In the simplest case, a plit is just the keyword PLIT or UPLIT followed by a 
parenthesized list of plit-expressions or plit-strings. In this case, values of the 
items are laid out in storage, starting at the plit address and continuing in the 
direction of increasing addresses. The value of each plit-expression occupies a 
fullword. The value of each string-literal occupies as many character positions 
as the string requires, with unused character positions added, if necessary, to 
fill out the final fullword. 

BLISS-16/32 ONLY 

When an allocation-unit is present, it specifies explicitly the unit of storage 
to be used. Depending on whether the allocation-unit is LONG, WORD, or 
BYTE, the value of each plit-expression occupies a longword, a word, or a 
byte, respectively. Similarly, the value of each string-literal occupies as 
many bytes as the string requires, with unused bytes added, if necessary, to 
fill out the last unit of storage. (The allocation-unit LONG and the long- 
word storage unit apply to BLISS-32 only.) 

When an allocation-unit is given, the item or items to which it applies are 
enclosed in parentheses. Several allocation-units can be used in a single 
plit; for any given item, the innermost allocation-unit is the one that 
applies. 

When both a psect-allocation attribute and an allocation-unit of storage are 
used in a plit they may appear in any order. For example: 

PLIT PSECTt $OWN$ ) BYTE(7) 

The psect-name ( $OWN$ in the example) specified in the attribute must be 
either predeclared, a default program-section name, or explicitly declared in a 
preceding psect-declaration. 
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The psect-allocation attribute provides a more convenient way of making 
program-section assignments for a plit than is possible using the psect-decla- 
ration alone (see Section 9.8). 

When a "replicator OF" construct is present, it specifies the repetition of the 
plit-group that follows it. The plit-group is evaluated before it is repeated. 
Thus, if the plit-group contains an embedded plit, the embedded plit is allo- 
cated once, and its address is used in each repetition of the plit-group. 

The evaluation of plits is performed by the compiler, the linker, and the 
operating system before program execution. Thus during program execution, 
a plit represents the constant address of a sequence of constant values. 

When the values specified by a plit do not completely fill the last fullword of 
the plit, the values of the unused character positions are undefined. A pro- 
gram that attempts to access the unused character positions is invalid. 

Plits are not necessarily allocated in the order in which they are written, and 
unused storage may be left between the storage for one plit and that for the 
next. Therefore, the relative positions of two plits is undefined. A program 
that depends on the relative positions of two plits is invalid. 

4.4.5 Pragmatics 

A plit-expression is not restricted to numeric-literals. It can be any link-time- 
constant-expression, and can therefore include address-valued names whose 
value is established at link time. Suppose the following declarations are 
given: 

ONN 

A; VECTOR [10] » 

b; 
external 
x; 

Then, within the scope of these declarations, the following plit can be used: 

UPLIT(AC4] t B + 2 » X) 

This plit occupies three full words. The first contains the address of the fifth 
element of A. The second contains the address B plus 2. The third fullword 
contains the address X. 



4.5 Names 



A name usually designates the address of a routine or a data segment. The 
value of such a name is determined by the compiler, linker, and operating 
system together. Within the scope of a given declaration of a name (as defined 
in Section 8.2), the value of a name does not change during program execu- 
tion. 
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4.5.1 Syntax 



name 


(I letter ) j 
{ letter ) \) digit ( / 
\ dollar > < ) dollar i ... > 
' underline/ 1 I underline J I 

1 nothing 1 


letter 


( A 1 B 1 C 1 — 1 Z ) 

( a 1 b 1 c 1 — 1 z J 


digit 


{ 1 1 1 2 1 — 19} 


dollar 


$ 


underline 


— 



A name can be constructed by the %NAME lexical-function, described in 
Section 15.5.4. A name constructed in that way can be composed of any 
sequence of ASCII characters and therefore need not satisfy the syntax given 
above. 

4.5.2 Restrictions 

A name must not be more than 31 characters long in any case. 

The reserved keywords, listed in Appendix A, must not be used as names. 

A name is a single lexeme and must not contain a space. 

The dollar character is reserved for use in software supplied by Digital. 

BLISS- 16/36 ONLY 

Names declared as global or external must be unique within their first six 
characters (throughout a program), to assure correct linking. 

4.5.3 Semantics 

When two names are compared, the distinction between uppercase and lower- 
case letters is ignored. Thus the following items are considered to be four 
instances of the same name: 

BETA beta Beta bEta 

This equivalence also applies to keywords. The only place where an uppercase 
letter is distinguished from a lowercase letter is in a quoted-string. 

The interpretation of a name depends on its declaration. Declarations are 
described in Chapter 8. 
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4.6 Blocks 

In its simplest form, a block is a means to gather together one or more expres- 
sions to form a single primary expression. In its more complicated forms, a 
block contains declarations and determines the scope of those declarations. It 
provides the fundamental large-scale unit of BLISS program structure. 

In the example 

5 * < ♦ A + .B) 

the block (.A + .B) serves to specify that the value of .A + .B is one of the 
operands of the multiply operator. 

The block 

X = BEGIN 

LOCAL T5 

T = 2 + F( ) 5 

T = .T * G( ♦T) 5 

• T 

END 

contains a declaration of a local data segment T which is used within the 
block as a temporary variable. When the block is completed, the contents of T 
becomes the value of the block, and is assigned to X. 

The complete description of blocks is given in Chapter 8. 

4.7 Structure-References 

When a data segment consists of "a structure of several values, a structure- 
reference is used to fetch or store the individual values. A structure-reference 
can also be used to designate the address of a contained value. 

Examples of expressions containing structure -references are: 

X = . A C . I 3 

TABLECQ( ,X+2)+3] = 5 

F(ALPHAC FIELDNAME t ♦ J-i] ) 

The complete description of structure-references* is given in Chapter 11. 

4.8 Routine-Calls 

A routine-call causes the execution of a routine. The called routine may be a 
part of the same module that calls it or it may be part of another module in 
the same program. The routine may be written in BLISS or in some other 
language that is supported by the target system. 

The execution of a routine can have two kinds of effects. First, it can calculate 
a value that is returned as the value of the routine-call. Second, it can have 
side effects; that is, it can perform actions other than returning a calculated 
value, such as modifying data, performing input/output, and so on. 
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The expression "X = F()" calls the routine named F but does not pass any 
arguments. The value returned by F is assigned to location X. 

The expression 

Pv5> ,X» UPLIK 'MESSAGE' )) 5 

calls the routine named P and passes three arguments: the value 5, the con- 
tents of location X and the address of an ASCII string. The value returned by 
routine P, if any, is not used. 

The complete description of routine-calls is given in Chapter 12. 

4.9 Field-References 

A field-reference can designate any portion of storage of up to %BPVAL bits 
in length. That is, it designates a field value that can range in size from one 
bit to a fullword. In BLISS-32, for example, the field can be a sequence of up 
to 32 bits. Normally, a field-reference is used only within a structure-declara- 
tion. 

The full description of field-references is given in Chapter 11. 

4.10 Codecomments 

A codecomment places a comment in the object part of the compilation listing 
of the module in which it appears. Thus codecomments permit annotation of 
the object code. 

In addition, a codecomment acts as a barrier to optimizations that are nor- 
mally performed by the compiler, in that such optimizations do not cross the 
codecomment. Thus it divides the source listing and the object listing into 
portions that contain mutually corresponding source and object code. 

4.10.1 Syntax 



codecomment 



CODECOMMENT quoted-string ,... : block 



4.10.2 Semantics 

The value of a codecomment expression is the value of the block. 

A codecomment places the given quoted-string in the object code listing in the 
form of an assembly language comment. 

A codecomment expression prevents code motion. That is, expressions in the 
source that appear before the codecomment expression are compiled into 
instructions in the object code that precede the generated comment, and 
source expressions that follow the codecomment expression are compiled into 
instructions that follow the generated comment. 
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A codecomment has other effects on optimization. For example, the compiler 
will not place a value in temporary storage (such as a register) prior to a 
codecomment and then fetch the value after the codecomment. Instead, the 
compiler recalculates the value. 

A general description of optimization is given in the user's guide for each 
BLISS compiler. 
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Chapter 5 

Computational Expressions 



The computational expressions of BLISS provide the operations of the lan- 
guage. A single computational expression performs a single basic operation, 
like addition or the fetching of a value. A combination of computational 
expressions, nested one within another, can perform a long and complicated 
sequence of operations. 

Computational expressions are classified as either operator-expressions or exe- 
cutable-functions. A typical operator-expression is A=0; it assigns a value, 
that is, places a value in storage. It is identified by the "=" operator that 
appears between the two operands, A and 0. A typical executable-function is 
MAX(.X,.Y,.Z); it selects the maximum of several values, and it is identified 
by the keyword MAX that precedes the parameters .X, .Y, and .Z. All compu- 
tational expressions, regardless of their syntax, perform a predefined opera- 
tion on given values to produce a result value. 



5.1 Operator-Expressions 



The notation used for the operator-expressions of BLISS is similar to the 
notation of mathematics. The terms "operator", "operand", and "associa- 
tivity" that are used in describing BLISS expressions are all drawn from the 
terminology of mathematics. 
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5.1.1 Syntax 



The following syntax diagram gives the many forms of the operator-expres- 
sion. The forms are divided by broken lines into priority levels, and an associ- 
ativity is given for each priority level. This information is used in Section 
5.1.3." 
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Every operator-expression has one of the following general forms: 

prefix-operator right-operand 

left-operand infix -operator right-operand 

The operands must be expressions and the operator is either a keyword or a 
single delimiter character. 

5.1.2 Restrictions 

An operator-expression must not have an operand that is a control-expression. 
This restriction is expressed in the syntax (in the rule that defines el and e2, ) 
but is repeated here for emphasis. For example, the operator-expression 

X = IF .ALPHA EQL THEN ,X1 ELSE ,X2 

is not valid. (Parentheses can be used to avoid this restriction, by converting 
the right-operand to a compound-expression; see Sections 8.1 and 5.1.5.1.) 

A prefix-operator must not immediately follow an infix or prefix operator that 
has a higher priority. For example, 

.A EQL NOT ,B 

is not valid. (Parentheses can be used to avoid this restriction, as above; see 
Sections 8.1 and 5.1.5.1.) 

The result of an arithmetic operation ("*", "/", "MOD", "+", and "-") must 
not exceed the capacity of a signed fullword; if it does so, the result is unde- 
fined. 

The value of the right operand of a "MOD" or "/" operator must not be zero. 

5.1.3 Defaults 

The default parenthesization for operator-expressions is determined by the 
priority levels and associativities given in the syntax diagram for operator- 
expressions. The following rules apply: 

1. Parenthesize the operators of a given expression in order of descending 
priority. That is, first parenthesize all fetch operators (highest priority), 
then parenthesize all prefix "+" and "-" operators (second highest 
priority), then continue in this manner through operators of decreas- 
ing priority, and finally parenthesize all assignment operators (lowest 
priority) . 

2. If an expression contains several occurrences of operators that have a 
given priority, then parenthesize those operators in the order indicated 
by the associativity. If the associativity for a given priority level is "left 
to right", then parenthesize operators with that priority from left to 
right; if the associativity is "right to left", then parenthesize from right 
to left. 

When an operator is parenthesized, the parentheses surround the operator 
and the one or two operands required by the operator. 
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As an example of the application of these rules, consider the following expres- 
sion: 

3*R(B)-2*. A+12 

This expression contains four operators, and there are many ways in which it 
could be explicitly parenthesized. The default parenthesization is obtained as 
follows: 

1. The fetch operator has the highest priority and is parenthesized first, 
giving: 

3*R(B) -2*( . A)+12 

2. Of the remaining operators in the expression, the two "*" operators 
have the highest priority and are parenthesized next, giving: 

<3*R(B) ) - <2*< . A) )+12 

3. The remaining operators are "-" and "+" used as infix operators. These 
operators have the same priority level and so associativity must be 
taken into account. Since associativity is "left to right" for these opera- 
tors, the "-" is parenthesized first, giving: 

( (3*R(B) ) - <2*< .A) ) ) + 12 

4. Finally, the remaining operator, "+" is parenthesized, giving: 

( ( (3*R(B) ) - (2*< ,A) ) )+12> 

This fully-parenthesized expression is equivalent to the original, unparen- 
thesized expression. 

Observe that, in the example just given, the routine-call is treated as a single 
construct because it is a complete primary. That is, 3*R(B) is parenthesized 
as (3*R(B)) rather than (3*R)(B). Structure-references and field-references 
are treated as a single construct in a similar way. 

Explicit parenthesization is discussed in Section 5.1.5.1. 

5.1.4 Semantics 

An operator-expression is evaluated as follows: 

1. Evaluate the operand(s) of the expression. 

2. Calculate a value according to the specific rules for the given operator. 

The value obtained in Step 2 is the value of the expression. 

In general, the order in which the operands of an operator-expression are 
evaluated is not defined. (See Section 5.1.5.2.) 

The order in which assignment expressions, routine-calls, and control-expres- 
sions are evaluated is, however, defined as follows: 

Every evaluation of an assignment expression, routine-call, or control-ex- 
pression in the left operand of an operator-expression is completed before 
any evaluation of an assignment expression, routine-call, or control-expres- 
sion in the right operand of the operator-expression is begun. 
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(The consequences of this ordering rule are discussed in Section 5.1.5.2.) 

The value of every BLISS expression is a full word value. It follows that the 
value of the operands of an operator-expression are fullword values and that 
the value of the operator-expression itself is a fullword value. 

In some cases, an operator-expression produces a value that cannot be repre- 
sented as a fullword value. In such cases, the value of the expression is unde- 
fined and the program is invalid. There is no guarantee that such an overflow 
is detected or signaled. 

The remainder of this description of semantics is devoted to specific rules for 
the various operator-expressions. The operator expressions are grouped ac- 
cording to function, but they are nevertheless described in the order in which 
they appear in the syntax diagram; that is, in order of decreasing priority. 

5.1.4.1 Fetch Expressions — A fetch expression obtains the value that is 
stored at a given address. The expression has the form: 



The operand of a fetch expression can be a field-reference that has a field- 
selector; in that case the fetch expression has a special interpretation. How- 
ever, the use of a field-selector outside of a structure-declaration is not recom- 
mended. For that reason, the effect of a field-selector on a fetch expression is 
described later, in Section 11.2. 

A fetch expression without a field-selector is evaluated as follows: 

BLISS-16/32 ONLY 

1. If e2 is the name of a data-segment, then determine its allocation-unit 
and extension-attribute from its declaration. If e2 is any other expres- 
sion, then use the default allocation-unit (WORD for BLISS-16, LONG 
for BLISS-32) and use UNSIGNED as its extension-attribute. 

2. Interpret the value of e2 as an address. Depending on whether the 
allocation-unit of e2 is LONG, WORD, or BYTE, fetch the contents of 
the longword, word, or byte at that address. (LONG and longword 
apply to BLISS-32 only.) 

3. If the value fetched in Step 2 is a field value (less than 96BPVAL bits 
long), interpret it as a signed or unsigned value depending on the exten- 
sion-attribute. If the attribute is UNSIGNED, then extend it to a full- 
word value by placing O's at the left end. If the attribute is SIGNED, 
extend it to a fullword value by placing copies of the left-most (sign) bit 
at the left end. 

4. Use the fullword value obtained in Step 3 as the value of the fetch 
expression. 

BLISS-36 ONLY 

1. Interpret the value of e2 as an address and fetch the contents of the 
fullword at that address. 
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2. Use the fullword value obtained in Step 1 as the value of the fetch 
expression. 

5.1 .4.2 Prefix Sign Expressions — A prefix sign supplies the algebraic sign for 
a given value. The expression has the following forms: 



{:! 



e2 



The expression is evaluated as follows: 

• If the operator is " + ", then the value of the expression is the value of e2. 

• If the operator is "-", then the value of the expression is the negative 
(two's complement) of the value of e2. 

5.1.4.3 Shift Expression — This expression performs operations based on the 
arithmetic shift instruction of the target system. The expression has the fol- 
lowing form: 

el "• e 2 

This operation can be explained in terms of a hypothetical shift register that 
is valid for all BLISS dialects. The register has n bit positions, where n is 16, 
32 or 36 depending upon the target system (%BPVAL). The positions are 
numbered starting at the right with position (the low-order position) and 
ending with position n-1 (the sign position), referred to below as position m. 

To evaluate an arithmetic shift expression, place the value of el in the shift 
register and let the value of e2 be called v2. Proceed as follows: 

a. If v2 is positive, move each bit v2 positions to the left. When a bit is 
moved out of the sign position, m, discard it. When a bit is moved out of 
position 0, put a zero-bit in position 0. 

b. If v2 is zero, do not move any bits. 

c. If v2 is negative, move each bit ABS(v2) positions to the right. However, 
do not modify the bit in position m (the sign position). When a bit is 
moved out of position m-1, put a copy of the sign bit in position m-1. 
When a bit is moved out of position 0, discard it. 

When the shift is complete, use the contents of the shift register as the value 
of the shift expression. 

Sometimes an arithmetic shift is used for scaling; that is, to multiply a value 
by a power of two. For that application, the following interpretation of an 
arithmetic shift is more appropriate: 

1. Let vl and u2 be the signed values of the operands and calculate the 
following value: 

vl*(2**v2) 

In this expression, 2**v2 means "2 to the power v2". 

2. If the result of Step 1 is not an integer, reduce it to the next smallest 
integer. For example, reduce 2.5 to 2 and reduce -2.5 to -3. 
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3. Represent the result of Step 2 as a signed, two's complement binary 
integer. If the result requires more than %BPVAL bits for its represen- 
tation, some of the high-order bits of the representation are lost. 

This interpretation is entirely equivalent to the interpretation in terms of a 
shift register; it is just another way of looking at the same operator. 

Examples of arithmetic shift operations are given in the following table: 

vl v2 2**v2 vl*(2**v2) vl A v2 



10 


2 


4 


40 


40 


10 


2 


4 


-40 


-40 


10 


-2 


0.25 


2.5 


2 


10 


-2 


0.25 


-2.5 


-3 



All the values in this table are decimal numbers. Observe that when v2 is 
positive, the arithmetic shift performs multiplication by a power of 2. When 
v2 is negative and vl is positive, the shift performs division by a power of 2. 
When v2 and vl are both negative, the shift performs something close to, but 
not quite the same as, division by a power of 2. 

5.1.4.4 Arithmetic Expressions — The multiplication, division, addition, and 
subtraction expressions perform the operations of ordinary arithmetic. The 
modulus (MOD) expression obtains the remainder of a division. The expres- 
sion has the following form: 

* 
el < MOD > e2 



The values of the operands are interpreted as signed values, and the result is 
represented as a signed value. If the result is outside the range provided by a 
signed fullword, then the expression is invalid and the value of the expression 
is undefined. 

Let vl and v2 be the values of the operands. The expression is evaluated as 
follows: 



• 



• 



If the operator is "*" (multiplication), then multiply vl by v2 and use the 
result as the value of the expression. 

If the operator is "/" (division), then proceed as follows: 

a. If v2 is zero, the expression is invalid and the value of the expression is 
undefined. 

b. Otherwise, divide vl by v2. If the result is not an integer, drop its 
fractional part without rounding (so that 2.8 becomes 2 and -2.8 be- 
comes -2). Use the result as the value of the expression. 

If the operator is "MOD" (modulus), then proceed as follows: 

a. If v 2 is zero, the expression is invalid and the value of the expression is 
undefined. 
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b. Otherwise, divide vl by u2. Drop the fractional part of the value (so 
that 2.8 becomes 2.0 and -2.8 becomes -2.0). 

c. Multiply the value obtained in Step b by v2. 

d. Subtract the value obtained in Step c from vl and use the result as the 
value of the expression. 

• If the operator is "+" (addition), then add v2 to vl and use the result as 
the value of the expression. 

• If the operator is "-" (subtraction), then subtract v2 from vl and use the 
result as the value of the expression. 

The MOD operator is the remainder of the division of vl by v2. An aid to 
understanding the MOD operator is the identity: 

(vl MOD v2) EQL (vl-v2*(vl/v2)) 

Some examples of the "/" and MOD operations are: 



vl 


v2 


vl/v2 


vl MOD v2 


10 


3 


3 


1 


10 


-3 


-3 


1 


-19 


7 


-2 


-5 


-19 


-7 


2 


-5 


13 


2 


6 


1 


13 


8 


1 


5 


13 


10 


1 


3 


13 


16 





13 



The last four examples show how the MOD operator is used to obtain the last 
digit of the binary, octal, decimal, and hexadecimal representations of 13. 

5.1.4.5 Relational Expressions — A relational expression is used to compare 
two values. The expression has the following form: 



el 



EQL 

NEQ 

LSS 

LEQ 

GTR 

GEQ 



EQLU 

NEQU 

LSSU 

LEQU 

GTRU 

GEQU 



EQLA \ 
NEQA J 
LSSA ( 
LEQA ( e2 
GTRA 1 
GEQA/ 



The interpretation of the operator itself is determined by the first three letters 
of the operator, as follows: 

EQL is equal to 

NEQ is not equal to 

LSS is less than 

LEQ is less than or equal to 

GTR is greater than 

GEQ is greater than or equal to 
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The interpretation of the operands is determined by the fourth letter of the 
operator as follows: 

No fourth letter: Interpret operand values as signed values. 

Fourth letter is U: Interpret operand values as unsigned values. 

Fourth letter is A: Interpret operand values as address values. 

If the values of the operand satisfy the relation specified by the operator, then 
the value of the relational expression is "1"; otherwise, it is "0". In both cases, 
the value is represented as a full word value. 

In both BLISS-16 and BLISS-32, the operators LSSU and LSSA are equiva- 
lent, as are GTRU and GTRA, LEQU and LEQA, and GEQU and GEQA. 
That is, the unsigned and address forms of the 'magnitude sensitive' rela- 
tional operators are equivalent. In BLISS-36, however, the operators LSS 
(signed) and LSSA are equivalent, as are GTR and GTRA, and so on. This 
reflects a difference in the range of valid address values allowed by the corre- 
sponding systems. The distinction between the signed/unsigned and the ad- 
dress forms of the operators is provided so that programmers can specify the 
desired interpretation of the values being operated on, in a both explicit and 
transportable fashion. 

Note that all forms of the EQL and NEQ operators are by nature equivalent 
in all dialects; the unsigned and address forms are provided for symmetry 
with the other relational operators discussed above. Use of the alternate forms 
is encouraged for the sake of clarity. 

Two examples of the use of relational expressions are: 

Expression Value 

-1 LSS 1 (true) 

-1 LSSU (false) 

As another example, consider the following program fragment: 

OWN 



A t 

YS 



X LSSA Y 

The value of the relational-expression in this example is 1 (true) because X is 
allocated at a smaller address than Y. 

5.1.4.6 Boolean Expressions — A Boolean expression is used to apply a 
Boolean operation to given values. The expression has the following forms: 

NOT e2 



/ AND \ 
I OR I 
| XOR ( 
V EOV / 



el < wxv > e2 
XOR 

EQV 
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Each of these expressions operate on the individual bits of the operands to 
produce the individual bits of the result. The specific rules are: 

• If the operator is NOT, then the i'th bit of the result is obtained from the 
i'th bit of the value of e2 according to the following table: 

e2 NOT 

1 

1 

• If the expression has two operands, then the i'th bit of the result is 
obtained from the i'th bit of the value of el and the i'th bit of the value of 
e2 according to the following table: 

el e2 AND OR XOR EQV 

1 

1 11 

10 11 

11 1 10 1 

The appropriate rule is applied %BPVAL times, once for each bit in the 
result. 

Boolean logic applies to single bits while BLISS always operates on full words. 
Therefore special precautions are sometimes required in programming Bool- 
ean logic in BLISS. 

Suppose, for example, that A is thought of as the name of a Boolean variable; 
that is, a variable whose value is always or 1. Suppose, further, that the 
negation of the contents of A must be assigned to another Boolean variable, 
which is named B. The following assignment might be tried out: 

B = (NOT .A); 

However, this assignment does not produce a Boolean value. Instead, its effect 
(assuming a BLISS-32 fullword, for example) is: 

Contents of A Contents of B 

11111111111111111111111111111111 (binary) 

1 11111111111111111111111111111110 (binary) 

The low-order bit is the desired Boolean result, but the other bits clutter up 
the result. To assign a Boolean value to B, the high-order bits can be masked 
out as follows: 

B = ((NOT .A) AND 1); or B = .A XOR 1; 

5.1.4.7 Assignment Expressions — An assignment expression is used to store 
a given value at a given address. The form of the expression is: 

el = e2 

The left operand of an assignment expression can be a field-reference that has 
a field-selector; in that case the assignment expression has a special interpre- 
tation. However, the use of a field-selector is not recommended outside of a 
structure-declaration. For that reason, the effect of a field-selector on an 
assignment expression is described later, in Section 11.2. 
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An assignment-expression without a field-selector is evaluated as follows: 

BLISS-16/32 ONLY 

1. If el is the name of a data segment, then determine its allocation-unit 
from its declaration. If el is any other expression, then use the default 
allocation-unit (WORD for BLISS-16, LONG for BLISS-32). 

2. Interpret the value of el as an address. Depending on whether the 
allocation-unit of el is LONG, WORD, or BYTE, store the correspond- 
ing number of rightmost bits of the value of e2 in the longword, word, or 
byte at the given address. (LONG and longword apply to BLISS-32 
only.) 

3. Use the original value of e2 (that is, the fullword value) as the value of 
the assignment expression. 

BLISS-36 ONLY 

1. Interpret the value of el as an address and store the value of e2 in the 
fullword at the given address. 

2. Use the value of e2 as the value of the assignment expression. 

5.1.5 Pragmatics 

Two aspects of the interpretation of operator-expressions are discussed here: 
the effect of explicit parenthesization, and the order of expression evaluation. 

5.1.5.1 Explicit Parenthesization — Any expression can be placed in 
parentheses. The value of the parenthesized expression is the value of the 
expression within the parentheses. The effect of the parentheses is to delimit 
the operands of the expression. Consider the following expressions: 

( . A)+l 

♦ (A+l ) 

The two different placements of the parentheses produce two expressions that 
are not equivalent. In the first example, the operand of the fetch operator is 
just A, while in the second example, it is A+l. 

Every expression is fully parenthesized, if necessary, by the compiler to deter- 
mine which operands go with each operator, according to the default rules 
given in Section 5.1.3. For example, the default parenthesization of the ex- 
pression .A+l is: 

< . A>+1 

This parenthesization follows from the fact that the fetch operator has higher 
priority than the addition operator. The expression could be explicitly paren- 
thesized, however, as 

• (A+l > 

to specify the interpretation required. 
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Sometimes an operator-expression must be explicitly parenthesized because 
of restrictions that prohibit the use of certain operands (see Section 5.1.2). 
Any operand can, itself, be a parenthesized expression because a paren- 
thesized expression is a form of block (as defined in Section 8.1), which is a 
primary (as defined in Section 4.1). For example, the expression 

X = (IF .ALPHA EQL THEN ,X1 ELSE «X2) 

is valid but the unparenthesized form is not. Again, the expression 

,A EQL (NOT ,B) 

is valid, but the unparenthesized form is not. 

5.1.5.2 The Order of Evaluation — As stated in Section 5.1.4, the order in 
which operator-expressions are evaluated is largely undefined. By leaving the 
order undefined, the language definition permits the compiler to choose an 
order of evaluation that is efficient. 

In most cases, the results of programs are not affected by the absence of a 
defined order of evaluation. Consider, for example, the following expression: 

X = 2*.X + 3/.Y5 

The absence of a defined order of evaluation does not affect the value assigned 
to X because all possible orders of evaluation of this assignment (after the 
operands are delimited by default parenthesization) produce the same value. 

The rule near the beginning of Section 5.1.4, however, states that assignment 
expressions, routine-calls, and control-expressions are evaluated in left-to- 
right order. In some cases where the order of evaluation is important, this 
rule provides the necessary ordering. Consider, for example, the following 
example: 

BETA = 2*R( ♦ Y) + Q( .Z) 

Suppose that R and Q are names of routines, and that the routines they 
designate use the same data (for example, R sets a data segment that Q 
fetches). Then it is important that the routines be called in the indicated 
order. They are. 

It must be said, however, that the example just given is not good program- 
ming. It is legitimate for a routine-call to set or use data that is not mentioned 
in the routine-call, but a dependence between two routine-calls in the same 
expression is dangerously obscure. 

Some expressions are invalid because they depend on an ordering that is 
undefined. An example is the expression: 

o = . x + ( x = ♦ y ) ; 

It is not valid to assume that the contents of X will be fetched before it is set. 
The value assigned to Q could be either the value of .X+.Y or the value of 
2*.Y. Assuming that it was the first of the two values that was intended, the 
example can be revised by breaking it into two assignments, as follows: 

= ♦ X + . Y 5 
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This version is valid because expressions that are separated by a semicolon 
are always evaluated in sequence, one at a time. 

The example just given was quite obviously bad programming. However, the 
same problem can arise with certain routine-calls, and then the problem is 
less obvious. As an example, suppose that the routine R contains, among 
other things, the assignment expression: 



Now consider the expression: 

o = , x + r ( ) ; 

This statement has the same problem as the earlier one; there is no rule that 
specifies whether the operator that fetches X or the call on the routine R is 
evaluated first. 

5.1.5.3 Operations on Field Values in BLISS-16/32 — When all data segments 
involved in a calculation occupy fullwords, the calculation is relatively easy to 
program. Fullwords accomodate large values and assignment from one full- 
word to another never modifies a value. 

When a data segment that is smaller than a fullword is involved in a calcula- 
tion, problems can arise, either through the assignment of a large value to the 
small data segment or through the incorrect extension of the contents of the 
small data segment. An example of the latter problem is: 

OWN 

X: BYTE , 



X = - 1 5 

Y = ♦ X + 15 

For purposes of discussion, assume that the programmer has a good reason for 
restricting X to one byte. Since X does not occupy a fullword, it is extended 
before being incremented and assigned to Y. And since X is UNSIGNED by 
default, the extended value is 255 rather than -1. Thus the value of Y be- 
comes, surprisingly, 256 rather than 0. 

The program fragment under discussion does not violate any rules of 
BLISS-16 or BLISS-32; it is valid. However, since it assigns a negative num- 
ber, -1, to a name that is declared UNSIGNED by default, the program 
fragment is certainly inconsistent. 

The program can be fixed in either of the following ways: 

• Change the numeric literal from -1 to 255. This change does not affect the 
value assigned to Y, but it does make it clear that the programmer ex- 
pects that result. 

• Insert the SIGNED attribute to the declaration of X. This change causes 
to be assigned to Y. 

The choice between these changes depends entirely on the intentions of the 
programmer and cannot be made by looking at this small part of the program. 
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Related problems can arise (in any dialect) from the use of field-references for 
fields that are smaller than a full word. These are discussed in Section 
11.2.5.4. 
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The executable-functions are called "executable" to distinguish them from 
the lexical-functions, which are described in Chapter 15. There are five kinds 
of executable-functions, as follows: 

standard-functions 

supplementary-functions 

condition-handling-functions (BLISS-16/32 only) 

linkage-functions 

machine-specific-functions 

Each of these kinds of function is characterized in the following paragraphs. 

The standard- functions are general-purpose functions; that is, they are re- 
stricted to neither a specific area of system programming nor a specific com- 
puter system. The standard-functions are just as fundamental to BLISS as 
the operator-expressions. An example of a call on a standard -function is: 

MAX< . X t ♦ Y » 0) 

The value of this function is the contents of X, the contents of Y, or 0, 
whichever is greatest. The name MAX is predeclared as an executable-func- 
tion, so the example just given can appear where MAX is undeclared. The 
standard-functions are defined in this chapter (Section 5.2.2). 

The supplementary-functions are designed for particular areas of system pro- 
gramming. These functions are usually defined and documented in "pack- 
ages". One such package consists of the character handling functions. An 
example of a call on such a function is: 

X = CH$RCHAR< . PTR3) 5 

This assignment reads a character from the position selected by the contents 
of PTR3 and assigns it to X. The character handling functions are the only 
supplementary-functions defined in this manual. However, it is anticipated 
that other packages of supplementary-functions will be added to the language 
in the future. 

The condition-handling-functions are used for generating signals for unusual 
events or conditions and for controlling the subsequent processing of a signal 
(BLISS-16/32 only). These functions are defined in Chapter 17. 

The linkage- functions are used in combination with some linkages (calling 
sequences) to code routines in a more general way; for example, to code a 
routine that can be called with different numbers of parameters in different 
calls. The linkage-functions are defined in Section 13.6. 

The machine-specific-functions are designed for specific computer systems. 
Usually a machine-specific-function represents a single hardware instruction. 
Such a function permits the use of the hardware instruction without a "break 
out" to assembly language. The use of a machine-specific-function makes a 
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program machine-dependent. An example of the use of a machine-specific- 
function is not given here. Such an example would be misleading without a 
detailed description of the context in which it appeared. The use of machine- 
specific-functions requires knowledge of both the hardware instruction set and 
the optimization strategies of the compiler. Machine-specific-functions are 
described in the respective BLISS User's Guides. 

5.2.1 Syntax 



executable-function 


executable-function-name 

/ ( actual-parameter, ... ) x 
( nothing J 


executable- 
function-name 


( name ) 
( % name) 


actual-parameter 


expression 



5.2.2 Semantics 

The semantics of the executable-functions is nearly identical to that for oper- 
ator-expressions (see Section 5.1). The only difference is that the operation to 
be performed is specified by a name at the beginning of the executable- 
function (for example, "MAX") instead of by an operator. 

The semantics of the standard-functions are given in the following subsec- 
tions. The semantics of some supplementary-functions, the character han- 
dling functions, are given in Chapter 20. The semantics of the machine- 
specific-functions are defined in the User's Guide for each dialect. 



5.2.2.1 SIGN and ABS Functions — The SIGN and ABS functions are used to 
extract the sign and the absolute value, respectively, from a value. The func- 
tions have the form: 



(SIGN 
(ABS 



}(el) 



Either of these functions is a compile-time-constant-expression if its actual- 
parameter is a compile-time-constant-expression. The values returned by 
these functions are: 



Function 

SIGN( x ) 



Value 

+1 if x > 

if x = 

-1 if x < 



ABS( x ) 



x if x > 
(x) if x < 
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Examples of the use of the SIGN and ABS functions are: 

Example Value 

SIGN(5) +1 

ABS(5) +5 

SIGN(-5) -1 

ABS(-5) +5 

SIGN(O) 

ABS(O) 

Observe that, in each of these examples, 

SIGN(x)*ABS(x) EQL x 

5.2.2.2 MAX and MIN Functions — The MAX and MIN functions are used to 
select the largest and the smallest, respectively, from a set of values. The 
functions have the form: 

C MAX I MAXU I MAXA ) 

I MIN I MINU I MINA J ( el ' e2 "" } 

The interpretation of the function itself is determined by the first three letters 
of its name, as follows: 

MAX select the largest value 
MIN select the smallest value 

The interpretation of the operands is determined by the fourth letter of the 
function name as follows: 

No fourth letter: Interpret operand values as signed values. 

Fourth letter is U: Interpret operand values as unsigned values. 

Fourth letter is A: Interpret operand values as addresses. 

The value of the function is the largest or smallest of the values of the 
operands, depending on the function name. 

In both BLISS-16 and BLISS-32, the functions MAXU and MAXA are 
equivalent, as are MINU and MINA. That is, the unsigned and address forms 
of the MAX and MIN functions are equivalent. In BLISS-36, however, the 
functions MAX (signed) and MAXA are equivalent, as are MIN and MINA. 
This reflects a difference in the range of valid address values allowed by the 
corresponding systems. 

The distinction between the signed/unsigned and the address forms of the 
functions is provided so that programmers can specify the desired interpreta- 
tion of the values being operated on, in a both explicit and transportable 
fashion. 
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Examples of the use of the signed and unsigned maximum and minimum 
functions are: 

Example Value 

MAX(-1,0,1) 1 

MAXU(-1,0,1) -1 

MIN(-1,0,1) -1 

MINU(-1,0,1) 

These examples show the difference between the signed and unsigned func- 
tions. The signed functions treat -1 (which is represented as a fullword of l's) 
as a negative value, whereas the unsigned functions treat -1 as a large positive 
value. 

An example of the use of the address maximum and minimum functions is: 

OWN 

X; VECTOR C 10] t 

Y t 

Z5 
♦ ♦ ♦ 
Z = MAXA(XC5] »Y) 

The assignment sets Z to the value of Y because OWN data segments are 
allocated at increasing addresses. 

5.2.2.3 The %REF Function — The %REF function provides temporary stor- 
age for the value of an actual-parameter in a routine-call or executable-func- 
tion. The function has the form: 

%REF ( el ) 

The function can be used only as an actual-parameter in a routine- call or 
executable-function. 

The function is evaluated as follows: 

1. Allocate a temporary fullword and place the value of el in that fullword. 

2. Use the address of the temporary fullword as the value of the function. 

For purposes of discussion, suppose that a programmer has declared a routine 
called RHO. The details of the declaration are not given here. All that matters 
is that the routine has one parameter, which is the address of a given value, 
and returns a result which, presumably, depends on the given value. 

Suppose, now, that the value to be passed is not stored in a data segment but 
must, instead, be calculated. Specifically, it is the value of the expression: 
.X+l. It would not be correct to write: 

Y = RH0( *x+i ) ; 

In this version, .X+l would not be used as the given value (which was in- 
tended), but rather as the address of the given value. 
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A correct solution to the problem is to declare and use a temporary data 
segment name. However, the use of a temporary just to deal with a calculated 
parameter is inconvenient. The %REF function provides a better solution, as 
follows: 



OWN 



Y = RH0(7,REF( , X+l ) ) 5 

Observe that %REF is not an "undot" operation. The following calls are not 
equivalent: 

F ( X > 
F(ZREF( .X) > 

The routine-call F(X) passes the address of X as the actual-parameter of the 
routine F, while the second call passes the address of a temporary data seg- 
ment that contains a copy of the contents of X. 

5.2.3 Pragmatics 

The cost of evaluating a typical executable function is much less than the cost 
of evaluating a typical routine-call. The use of an executable-function usually 
does not produce a routine call; instead, it is compiled into a few instructions 
that are often designed precisely for the required operation. In contrast, a 
routine-call usually requires the passing of parameters, the creation of a stack 
frame, and the return of a result as well as the inevitable subroutine jump. In 
fact, the similarity between an executable-function and a routine-call does 
not extend much beyond the similarities in their syntax. 
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Chapter 6 

Control Expressions 



Early programming languages permitted unrestricted patterns of control flow, 
and the logic of many programs was very difficult to follow. More recent 
languages have introduced specialized and restricted patterns of flow, and 
thus encourage the construction of programs that are better organized. 

There are five fundamental kinds of control flow in BLISS: sequential, condi- 
tional, iterative, subroutine, and condition handling. Sequential flow, a sim- 
ple notion, is defined in Section 8.1.3 as part of the description of blocks. 
Conditional and iterative flow is described in this chapter. Subroutine flow is 
described in Chapter 12, and condition handling in Chapter 17. 

Notable by its absence in BLISS is the familiar GO TO construct. Its absence 
prevents the use of arbitrary patterns of flow. Programming without the GO 
TO frequently requires more analysis of the problem, but usually results in a 
clearer and more reliable program. 

In BLISS, the constructs for conditional and iterative flow control are called 
control-expressions. Because they are expressions, these constructs can have 
values and can be nested within larger expressions. 

The syntax diagram for control-expressions is: 



control-expression 



{conditional-expression 
case-expression 
select-expression 
loop-expression 
exit-expression 
return-expression 



Loop-expressions are described under two categories: indexed-loops and 
tested loops. 



6-1 



6.1 Conditional-Expressions 



A conditional-expression performs a given test and then, depending on 
whether or not the test is satisfied, evaluates the first or second of two given 
expressions. 

An example of a conditional-expression is: 

IF ♦>< GTR XMAX THEN F(.X) ELSE G(.X)5 

In this example the contents of X is compared with a value XMAX. If .X is 
greater than XMAX, then the routine F is called; otherwise, routine G is 
called. 



6.1.1 Syntax 



conditional- 
expression 


{ IF test THEN consequence ELSE alternative \ 
\ IF test THEN consequence J 


test \ 
consequence > 
alternative ) 


expression 



In addition to the syntactic rules just given, the following syntactic rule is 
required: 

An "ELSE alternative" that could be part of several conditional-expres- 
sions is, in fact, part of the innermost of them. 

An example of an expression to which this rule applies is: 

IF ,A EOL THEN IF ,B EOL THEN X = 5 ELSE X = G5 

This expression is interpreted as: 

IF .A EOL THEN (IF ,B EOL THEN X = 5 ELSE X = G)5 

6.1.2 Restrictions 

A conditional-expression that lacks an "ELSE alternative" must not be used 
in a context that requires a value. 

6.1.3 Semantics 

The satisfaction of a test depends on the low-order (rightmost) bit of the value 
of the test. If the low-order bit is 1, the test is satisfied; otherwise, the test is 
not satisfied. 

Expressions used as test expressions are subject to an evaluation rule that is 
more flexible (for optimization purposes) than the rule applied in other con- 
texts. Specifically, the test-expression evaluation rule is: 

Within a test expression, an expression that is not needed to determine the 
value of the test expression is not necessarily evaluated. 
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A test expression that is subject to this rule appears in the following condi- 
tional-expression: 

IF ,A OR F( .B) THEN X = 

If the contents of A is 1 (true), then the value of the entire test expression is 1 
(true) regardless of the value of F(.B). Consequently, the call on routine F 
may not be evaluated. Writing the test in the reverse order does not change 
the situation. (See Section 6.1.4.3.) 

Given the preceding description of test evaluation, the interpretation for an 
entire conditional-expression can be presented. It is: 

1. Evaluate the test. 

2. If the test is satisfied, evaluate the consequence and use that value as 
the value of the conditional-expression. 

3. If the test is not satisfied and if an alternative is present, evaluate the 
alternative and use that value as the value of the conditional-expres- 
sion. If an alternative is not present, the value of the expression is 
undefined. 

6.1.4 Pragmatics 

6.1 .4.1 Nesting of Conditional Expressions — Conditional expressions provide 
a way to choose one of two mutually exclusive actions, depending on a speci- 
fied test condition. The test, consequence or alternative may be any expres- 
sion. It is common, for example, for the consequence or alternative to be a 
sequence of expressions (written as a block) as in: 

IF ,X EQL 

THEN (Y = ,Y+1 ! F( ,Y> i G( ) ) 

ELSE (G( ) 5 Y = ♦ Y-l ) 5 

Control expressions can also be included in these expressions. For example: 

IF (IF ,X EQL THEN ,Y ELSE F(.Y>) 
THEN 

Z = G( ) + 5? 

In this example, the following conditional-expression: 

IF , X EQL THEN . Y ELSE F(.Y) 

appears as the test expression of another, larger conditional-expression. The 
inner test, ".X EQL 0", determines which of the two expressions, ".Y" or 
"F(.Y)", is used as the test for the outer conditional. 

6.1.4.2 Used vs. Discarded Values — Every BLISS expression has a value; 
however, in some contexts that value is used and in others it is discarded. This 
aspect of BLISS is discussed here because the conditional-expression is a good 
example of an expression that is at home in both contexts. However, the 
following discussion applies to the value of any kind of BLISS expression. 

An example of a conditional-expression whose value is used is: 

D = (IF ,1 EQL ,J THEN 20 ELSE 30)5 
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Suppose that .1 and .J are equal; then 20, which is the value of the conse- 
quence, becomes the value of the conditional-expression and is assigned to D. 
Observe that, because the assignment expression is followed by a semicolon, 
its value is discarded, but only after the assignment has been performed. 

An example of a conditional-expression whose value is discarded is: 

IF .1 EQL . J THEN D = 20 ELSE D = 30 5 

Suppose, again, that .1 and .J are equal; then the evaluation of the conse- 
quence causes 20 to be assigned to D and also causes 20 to be the value of the 
conditional-expression. Since the conditional-expression is followed by a 
semicolon, its value is discarded. 

The two expressions just given are equivalent in function, and are close 
enough in their cost that the choice between the two examples is ordinarily a 
matter of programming style. 

6.1.4.3 Complete vs. Incomplete Test Evaluation — As Section 6.1.3 stated, a 
test may not be fully evaluated. Furthermore, different occurrences of the 
same test may be evaluated in different ways. These variations reflect the fact 
that the BLISS compiler performs a far-reaching analysis of the context in 
which a test appears and then produces code that is optimized for that con- 
text. For this reason, an expression that must be evaluated (because it sets 
values or has other side effects) must not be part of a test. 

If an assignment or routine-call must be evaluated, its value should be as- 
signed to a temporary variable. Then the value of the temporary variable can 
be used in the test expression. For example: 

IF .A OR F( .B) THEN X = 5 

can be rewritten as follows: 

T = F( ,B) 5 

IF .A OR . T THEN X = 5 



6.2 Case-Expressions 



A case-expression evaluates an index and then uses the value of that index to 
choose one expression to be evaluated from a set of expressions. 

An example of a case-expression is: 

OF 



CASE ,X+1 FROM 


-1 TO 8 


SET 




C 1 ] : 


Fl ( ) ; 


[2 TO ai : 


F2( ) 5 


C 5 , It - 1 ] : 


F3( ) ; 


I INRANGE] : 


F4( ) 5 


[OUTRANGE] : 


F5( ) ; 


TES 
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In this example, the value of .X+l is used to choose one of five routines to be 
called as follows: 



Value of .X+l 


Routine Called 


-1 


F3 





F4 


1 


Fl 


2 


F2 


3 


F2 


4 


F2 


5 


F3 


6 


F4 


7 


F3 


8 


F4 


(all other values) 


F5 



6.2.1 Syntax 



case-expression 


CASE case-index 
FROM low-bound TO high-bound OF 
SET 

case-line ... 
TES 


case-line 


[ case-label ,... ] : case-action ; 


case-label 


/ single-value \ 
1 low-value TO high-value 1 
1 INRANGE ( 
V OUTRANGE / 


case-index ) 
case-action J 


expression 


low-bound j 
high-bound 1 
single-value / 
low-value l 
high-value 1 


compile-time-constant-expression 



6.2.2 Restrictions 

Every value within the range specified by the low-bound and high-bound 
expressions must be accounted for exactly once in a case-expression. If an 
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integer value in the range is not explicitly given, a case-action must be speci- 
fied for INRANGE. 

If the case-index can assume a value outside the specified range, a case-action 
must be specified for OUTRANGE. 

If the INRANGE case-label is used, it must appear after all case-labels of the 
form: 

single-value 
or 

low-value TO high-value 

Thus the only case-label that can follow INRANGE is OUTRANGE. 

6.2.3 Semantics 

The matching of the case-index to a case-label determines the case-action to 
be evaluated. The syntax provides four kinds of case-label. The following list 
gives, for each kind of case-label, the condition under which a match occurs. 

Case-Label Condition for a Match 

single-value A match occurs if the values of the case-index 

and the single-value are equal. 

low-value TO high-value A match occurs if the value of the case-index 

is in the range specified by the values of the 
low-value and high-value expressions (that is, 
the following signed comparisons hold: low- 
value < case-index < high-value). 

INRANGE A match occurs if the value of the case-index 

is in the range specified by the values of the 
low-bound and high-bound expressions (that 
is, the following signed comparisons hold: low- 
bound < case-index < high-bound) and the 
case-index does not match any other case-la- 
bel. 

OUTRANGE A match occurs if the value of the case-index 

is outside the range specified by the values of 
the low-bound and high-bound expressions. 

Given the preceding definition of matching, the interpretation of an entire 
case-expression can be presented. It is: 

1. Evaluate the case-index. 

2. Evaluate the case-action in the case-line that contains the case-label 
matched by the case-index. 

3. Use the value of the case-action as the value of the case-expression. 

The case-expression is designed for a special, very efficient implementation. 
In order to make a decision about using a case-expression, a programmer 
needs to understand its implementation. A brief discussion follows. 
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The bounds and case-labels of a case-expression are all compile-time-con- 
stant-expressions and can therefore be evaluated by the compiler. For this 
reason, the compiler can prepare a transfer vector for use in the evaluation of 
a case-expression. The transfer vector has one element for each value of the 
case-index in the range from low-bound to high-bound. The first element of 
the vector provides the address of the object code for the case-action that is 
performed when the case-index is equal to low-bound. The second element 
provides the address of the object code for the case-action that is performed 
when the case-index is equal to low-bound plus one. And so on. 

When a case-expression is evaluated during program execution, only a single 
operation is required to get to the appropriate case-action. That is, the case- 
index is used as an index into the transfer vector. Thus a case-expression does 
not require a search through the case-labels. 

6.2.4 Pragmatics 

A case-expression is most useful when the case-index assumes values in a 
small range. An example of the effective use of a case-expression is: 

CASE ♦ TYPECODE FROM TO 3 OF 



SET 




CO]: 


LITERAL* > ; 


CI]: 


IDENTIFIER* ) 5 


C2] : 


KEYWORD ( > 5 


C3] : 


PREDCL< ) \ 


TES5 





This case-expression is used to choose the routine to be evaluated based on 
the value of .TYPECODE. The data segment named TYPECODE contains a 
code that is set earlier in the program. Since TYPECODE cannot assume a 
value outside the specified range, a case-action is not given for OUTRANGE 
and since each of the values within the range is associated with a specific case- 
action, a case-action is not given for INRANGE. 

Another example of a case-expression is: 

CASE • NUMBER FROM 1 TO 10 OF 
SET 
Clt2f3»5f73: PRIME = .PRIME + 15 

cinrange]: nonprime = .nonprime' + li 

coutrange] : error ( ) ? 

tes; 

This case-expression increments the counter PRIME if the contents of NUM- 
BER is 1, 2, 3, 5, or 7. If the contents of NUMBER is 4, 6, 8, 9 or 10, the 
counter NONPRIME is incremented. If the contents of NUMBER is outside 
the specified range, an error routine is called. 



6.3 Select-Expressions 



A select-expression evaluates an index and then uses the value of that index to 
choose one or more expressions to be evaluated. Two kinds of select-expres- 
sions are defined for BLISS: one evaluates all expressions chosen by the index, 
and the other only evaluates the first such expression. 
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A select-expression differs from a case-expression in several important ways: 

• Select-labels are evaluated at execution time. 

• A range of values is not specified for the select-index. 

• The select-index and select-labels can be interpreted as signed, unsigned, 
or address values depending on the form of the select expression used. 

An example of a select-expression, assuming the VAX-1 1/780 target system 
for purposes of illustration, is: 

SIZE= (SELECTONE .VALUE OF 
BET 

[-128 TO 127] : 1 i 
[-327G8 TO 327G7] : 2S 
[OTHERWISE]; 4? 
TES) 5 

In this example, the contents of VALUE is used to determine the number of 
bytes of storage needed for its representation. 

If the select-expression in this example is reprogrammed as a case-expression, 
it requires a range from -32768 to 32767, and its transfer vector occupies 65536 
16-bit words. For this reason, the case-expression is decidedly impractical for 
this example. (The particular example used and the transfer- vector size cited 
are not appropriate for all target systems, of course, but do convey the essen- 
tial differences between select- and case-expression usage.) 

6.3.1 Syntax 



select-expression 


( SELECT 1 SELECTU 1 SELECTA ) 
( SELECTONE 1 SELECTONEU 1 SELECTONEA J 

select-index OF 
SET 

select-line ... 
TES 


select-line 


[ select-label ,... ] : select-action ; 


select-label 


/ selector \ 
1 low-selector TO high-selector 1 
1 OTHERWISE 1 
V ALWAYS / 


select-index j 
select-action / 
selector > 
low-selector 1 
high-selector 1 


expression 
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6.3.2 Restrictions 

The select-label ALWAYS cannot be used in an expression that begins with 
SELECTONE, SELECTONEU, or SELECTONEA. 

6.3.3 Semantics 

The matching of the select-index to a select-label determines whether or not 
the select-action in the select-line containing the select-label is evaluated. 
The syntax provides four kinds of select-label. The following list gives, for 
each kind of select-label, the condition under which a match occurs. 

Select-Label Condition for a Match 

selector A match occurs if the values of the select-index and 

selector are equal. 

low-selector TO A match occurs if the value of the select-index is in the 
high-selector range specified by the values of the low-selector and 
high-selector expressions (that is, low-selector < select- 
index < high-selector). 

OTHERWISE A match occurs if a match has not previously occurred. 

ALWAYS A match always occurs. 

The keyword at the beginning of a select-expression consists of SELECT or 
SELECTONE, followed by an optional added letter, U or A. The added letter 
affects the matching of the select-index to a particular select-label. Specifi- 
cally, it determines the kind of comparison, as follows: 

No added letter: Use signed comparison. 

Last letter is U: Use unsigned comparison. 

Last letter is A: Use address comparison. 

Given the preceding discussion of matching and keywords, the interpretation 
for an entire select-expression can be presented. It is: 

1. Evaluate the select-index. 

2. Let the first select-line of the select-expression be the current select- 
line. 

3. Evaluate the select-labels on the current select-line to determine 
whether at least one of them matches the select-index. 

4. If a match is found, then evaluate the select-action of the current select- 
line. Otherwise, go to Step 6. 

5. If the select-expression is a form of SELECTONE, then go to Step 8. 

6. If the current select-line is the last select-line, then go to Step 8. 

7. Let the select-line that follows the current select-line be the new current 
select-line and go to Step 3. 

8. Use the value of the most recently evaluated select-action as the value 
of the select-expression. If no select-action has been evaluated during 
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this evaluation of the select- expression, use -1 as the value of the select- 
expression. 

In Step 3 of this interpretation, the select-labels in a single select-line may be 
evaluated in any order. Furthermore, they are subject to partial evaluation in 
the same way as a test in a conditional-expression (see Section 6.1.3). There- 
fore, a select-label must not contain assignments or routine-calls that must be 
evaluated because they have important side-effects. 



6.4 Indexed-Loop-Expressions 



A loop-expression repeatedly evaluates a given expression, the loop-body. 
Loop-expressions are classified as indexed-loops (described in this section) 
and tested-loops (described in the next section). 

An indexed-loop has a loop-index that starts at a given value and is stepped 
each time the loop cycles until a final value is reached. The loop-index not 
only determines the number of cycles performed by the loop, but can also be 
used as data in the calculations performed in the loop-body. An example of an 
indexed-loop is: 



OWN 



v: vector c 103 , 
sum; 



SUM = 5 

IIMCR I FROM TO 9 DO 

SUM = .SUM + . VC . I] i 

In this loop-expression, the loop-body is a single assignment-expression. The 
assignment-expression is evaluated ten times, for the sequence of values of .1 
as follows: 0, 1, 2, ..., 9. The effect of the loop is to place the sum of the 
elements of the vector V in the data segment named SUM. 

6.4.1 Syntax 



loop-expression 


( indexed-loop-expression ) 
( tested-loop-expression ) 


indexed-loop- 
expression 


( INCR 1 INCRU 1 INCRA ) . 

( DECR 1 DECRU 1 DECRA J loop-index 

< FROM initial ) ( TO final ) ( BY step ) 
( nothing J ( nothing J ( nothing ) 

DO loop-body 


loop-index 


name 


loop-body \ 
initial I 
final 1 
step * 


expression 
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6.4.2 Restrictions 

The value of the step expression in an indexed-loop-expression must be posi- 
tive. 



6.4.3 Defaults 

The initial, final, and step expressions can be omitted in an indexed-loop- 
expression. The following defaults apply: 

Keyword Defaults 

INCR FROM TO +infinity BY 1 

INCRU FROM TO +infinity BY 1 

INCRA FROM TO +infinity BY 1 

DECR FROM largest-signed-value TO BY 1 

DECRU FROM largest-unsigned-value TO BY 1 

DECRA FROM largest-address-value TO BY 1 

The default '^infinity" for INCR, INCRU, and INCRA loop-expressions 
means that no end test is made if no final expression is given. The "largest 
values" referred to are the maximum values accommodated by a signed or 
unsigned fullword, or the maximum address value provided, respectively, on 
the target system. 

6.4.4 Semantics 

The loop-index is implicitly declared to be a LOCAL name for the scope of the 
loop-body. This implicit declaration supersedes any previous declaration for 
that name throughout the indexed-loop. The MAP declaration, described in 
Section 10.10, can be used to provide a structure attribute for the loop-index. 

The keyword at the beginning of an indexed-loop-expression is INCR or 
DECR, followed by an optional added letter, U or A. The added letter affects 
the comparison of the index to the first and final expressions. Specifically, 

No added letter: Use signed comparison. 

Last letter is U: Use unsigned comparison. 

Last letter is A: Use address comparison. 

Given the preceding discussion of indexes and keywords, the interpretation for 
an entire indexed-loop-expression can be presented. It is: 

1. Set the value of the loop-index to the value of the initial expression. 

2. Evaluate the step and final expressions and save the values of these 
expressions. 

3. If there is no final expression (so that ^infinity" is assumed by de- 
fault), skip to Step 5. Otherwise, perform the end test. The end test is 
satisfied if: 

a. The keyword is INCR, INCRU, or INCRA, and the value of the loop- 
index is greater than the saved value of the final expression; or, 
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b. The keyword is DECR, DECRU, or DECRA and the value of the 
loop-index is less than the saved value of the final expression. 

4. If the end test is satisfied, evaluation of the loop-expression is complete. 
Use -1 as the value of the loop-expression. 

5. Evaluate the loop-body. 

6. If the keyword is a form of INCR, add the saved value of the step 
expression to the loop-index. If the keyword is a form of DECR, subtract 
the saved value of the step expression from the loop-index. Go to Step 3. 

6.4.5 Pragmatics 

The improper declaration of a loop-index is a common programming error. An 
example is: 

SUM = Oi 

INCR I FROM TO 9 DO 

BEGIN 

LOCAL 
I i 

SUM = .SUM + .YE , I ] ; 

END 5 

The preceding program fragment is incorrect because I is used as a loop-index 
and then "blocked off" from use in the loop-body by an explicit declaration of 
I as LOCAL. The name I in .V[.I] refers to a data segment that is allocated by 
the explicit declaration, not to the implicit data segment that contains the 
loop-index. The correct version of this example appears at the beginning of 
this section (Section 6.4). 



6.5 Tested-Loop-Expressions 



A tested-loop-expression contains a test expression that is evaluated once 
during each loop cycle. The test expression determines whether or not re- 
peated evaluation of the loop-body continues. 

In a pre-tested loop, the test is made at the beginning of each cycle. If the test 
is satisfied, then the loop-body is evaluated and a new cycle begins; otherwise, 
evaluation of the loop-expression is complete. An example of a pre-tested-loop 
is: 

WHILE .PTR NEQ DO 
BEGIN 

SUM = LISTC .PTR >C0NT] ; 
PTR = LISTC .PTR tLINK] 5 
END? 

In this example, the loop-body is the BEGIN-END block, with its two assign- 
ment-expressions. Each cycle of the loop begins with a test of the contents of 
PTR. If the value is not 0, then the block is evaluated and a new cycle begins; 
otherwise, evaluation of the loop-expression is complete. 

A post-tested-loop differs from a pre-tested-loop only in the position of the 
test. In a post-tested-loop, the test is evaluated at the end of each cycle. 
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6.5.1 Syntax 



tested-loop- 
expression 


( pre-tested-loop ) 
( post-tested-loop J 


pre-tested-loop 


{ UNTIL } * eSt D ° lo °P- bod y 


post-tested-loop 


DO loop-body { WHILE J ^ 



6.5.2 Restrictions 

The test in a pre-tested-loop or post-tested-loop is subject to the same evalua- 
tion rules as the test in a conditional-expression, described in Section 6.1.3. 
Assignments or routine-calls that must be evaluated because they set values 
or have other side effects must not be included as part of a test. 

6.5.3 Semantics 

The interpretation of a pre-tested-loop is: 

1. Evaluate the test. 

2. Examine the test clause (that is, the "WHILE test" or "UNTIL test"). 
The test clause is satisfied if the keyword is WHILE and the low-order 
bit of the test is 1 or if the keyword is UNTIL and the low-order bit of 
the test is 0. 

3. If the test clause is satisfied, evaluate the loop-body and return to 
Step 1. 

4. If the test clause is not satisfied, use the value -1 as the value of the 
loop-expression. 

The interpretation of a post-tested loop is: 

1. Evaluate the loop-body. 

2. Evaluate the test. 

3. Examine the test clause. If the test clause is satisfied, as defined in Step 
2 of the interpretation of the pre-tested-loop, return to Step 1. 

4. If the test clause is not satisfied, use the value -1 as the value of the 
loop-expression. 

6.5.4 Pragmatics 

The keywords WHILE and UNTIL are used to determine the continuation of 
a loop. If WHILE is used, then the loop continues if the low bit of the test 
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expression value is 1. If UNTIL is used, the loop continues if the low bit of the 
test expression is 0. Thus: 

WHILE test is equivalent to UNTIL NOT (test) 

The most fundamental form of loop is one that begins with: 

WHILE 1 DO 

Such a loop could cycle indefinitely since the loop test is always satisfied. 
Evaluation of the loop can be ended by an exit-expression (see Section 6.6) or 
a return-expression (see Section 6.7) that is executed within the loop-body. 



6.6 Exit-Expressions 



An exit-expression gives three items of information: a command to end the 
evaluation of a block, the label of the block to which the command applies, 
and optionally a value for the designated block. An example of an exit-expres- 
sion is: 

LEAVE ALPHA WITH »X-1 5 

This expression must occur in a block that is labeled ALPHA. It causes 
evaluation of that block to end and provides the value of .X-l as the value of 
that block. The labeling of blocks is described in Section 8.1. 

6.6.1 Syntax 



exit-expression 


C leave-expression ) 
\ exitloop-expression J 


leave-expression 


LEAVE label i WITH exit-value ) 
( nothing ) 


exitloop-expression 


EXITLOOP ( e xit-value ) 
( nothing J 


label 


name 


exit-value 


expression 



6.6.2 Restrictions 

A leave-expression must be contained in a block labeled by the same label 
that appears in the leave-expression. 

An exitloop-expression must be contained in a loop-expression. 
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If an exit-expression applies to an expression whose value is used, then the 
exit-expression must contain an exit-value. 

6.6.3 Semantics 

The semantics of the two kinds of exit-expression is presented in the following 
sections. 

6.6.3.1 Leave-Expressions — The interpretation of a leave-expression is: 

1. If an exit-value is given, evaluate the exit-value and use that value as 
the value of the labeled-block. 

2. If an exit-value is not given, the value of the labeled-block is undefined. 

3. End the evaluation of the labeled-block designated by the label of the 
leave-expression. 

6.6.3.2 Exitloop-Expressions — The interpretation of an exitloop-expression 
is: 

1. If an exit-value is given, evaluate the exit-value and use that value as 
the value of the loop-expression. 

2. If an exit-value is not given, the value of the loop-expression is unde- 
fined. 

3. End the evaluation of the innermost loop. 

6.6.4 Pragmatics 

An exitloop-expression is a special case of a leave-expression that leaves the 
innermost containing loop-expression. An exitloop-expression is convenient 
because it does not require the use of a label. 

An example of an exitloop-expression appears in the following program frag- 
ment: 

OWN 

X: VECTOR C 10] t 

zeroflag; 

zeroflag = 5 

i ncr i from to 9 do 

if . xc . i ] eql 

then (zeroflag = 15 exitl00p)! 

The elements of the vector X are examined to determine if there is an element 
whose contents is 0. If an element containing is found, then ZEROFLAG is 
set to 1 and evaluation of the loop-expression is ended by the EXITLOOP. 
Evaluation of the loop ends when the first zero is found; the elements of the 
vector following the first element containing are not examined. 
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An example of a leave-expression appears in the following program fragment: 

OWN 

XYZ: ARRAY C 10 tZOl > 

ZEROFLAG ! 
LABEL 

L ; 

ZEROFLAG = Oi ! Initialise to no zeros found 

L: BEGIN 

I NCR I FROM TO 9 DO 
I NCR J FROM TO 19 DO 

IF . XYZC . I t . J] EOL 

THEN (ZEROFLAG = 1! LEAVE L)i 
END i 

When the leave-expression is evaluated, it ends evaluation of two loops: the 
inner loop with index J and the outer loop with index I. 

The value of an exit-expression can be used to give a value to a loop. An 
example of this use of an exit-expression appears in the following program 
fragment: 

OWN 

valbuf: vector c 10] » 
buflen; 



BUFLEN = 1+ 
BEGIN 
DECR J FROM 9 TO DO 

IF .VALBUFC.J] NEO THEN EXITLOOP .J 
END i 

Assume that the initial elements of VALBUF contain non-zero values, and the 
remaining elements contain zero. BUFLEN is the number of non-zero values 
in VALBUF. Observe that if a non-zero value is found then the exitloop- 
expression ends the evaluation of the loop. If the buffer is all zeros, the 
evaluation of the loop runs to completion and the loop value is -1. In both 
cases, the value returned is 1 less than the desired number of values. 
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A return-expression is used to end the evaluation of a routine and send control 
back to the point at which the routine was called. 

6.7.1 Syntax 



return-expression 


RETURN [ ^turned-value ) 
( nothing J 


returned-value 


expression 
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6.7.2 Restrictions 

A return-expression in a routine that does not have the NOVALUE attribute 
must have a returned- value. 



6.7.3 Semantics 

The interpretation of the return-expression is: 

1. If the return-expression has a returned-value, evaluate the returned- 
value and use that value as the value of the routine- body. 

2. End the evaluation of the routine-body. 

Discussion of return-expressions is presented in the sections on the NO- 
VALUE attribute (Section 9.10) and routine-declarations (Section 12.2). 
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Chapter 7 

Constant Expressions 



A constant expression is an expression that can be evaluated before program 
execution begins. The practical and efficient implementation of BLISS re- 
quires that constant expressions be used in certain contexts, as specified in 
the syntax diagrams. An expression is a constant expression if certain restric- 
tions are met, and those restrictions are given in this chapter. 

There are two kinds of constant expression. The compile-time constant ex- 
pression is the more heavily restricted of the two, and can be evaluated during 
the compilation of the module in which it appears. The link-time constant 
expression includes the compile-time constant expression as a special case, 
and can be evaluated by the compiler, the linker, and the operating system 
working together. 

This chapter has two sections, one for each kind of constant expression. 

7.1 Compile-Time Constant Expressions 

This section defines compile-time-constant-expressions. The definition as- 
sumes the definition of expressions given in the previous chapters and then 
imposes restrictions. The restrictions are designed to permit a compile-time 
constant expression to be evaluated during the compilation of the module in 
which it appears. When the compiler encounters a compile-time constant 
expression, it evaluates that expression and makes use of its value in compil- 
ing efficient object code. 

Constant values known to the compiler are required in several places in 
BLISS in order to give a reasonable interpretation to another language fea- 
ture. For example, in order for the compiler to allocate static storage for plits, 
the actual sizes of all components must be known — including any repetition 
counts. The same consideration applies to the sizes of other static storage 
declarations, such as an own-declaration. 

In other cases, requiring constant values assures that an efficient implementa- 
tion can be provided by the compiler. For example, requiring that all LOCAL 
(and STACKLOCAL) storage allocation is of constant size and therefore 
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known to the compiler assures that storage allocation can be done efficiently 
and that LOCAL data segments can be addressed efficiently. 

Some simple examples of compile-time constant expressions are: 

5 

3 * 15 - a 

7 + ZC'A' 

MAX<3» 7, 3*15-4) 

Compile-time constant expressions often involve names that are declared 
LITERAL; for example: 



LITERAL 




REG 


= 5 t 


SIZE 


= 1X7 



BEGIN 

OWN X; UECTOR[MAX(SIZE »3)+l 3 5 

REGISTER A = REG 5 

♦ ♦ 4 

END 

Wherever the definition of BLISS requires a compile-time constant expres- 
sion, the syntactic name 

compile-time-constant-expression 

is used in the appropriate syntax diagram. There are quite a few contexts that 
require compile-time constant expressions, and they are scattered through the 
language. For convenience, a complete list follows. 

A compile-time constant expression must be used as 

The replicator in a plit (Chapter 4) 

The low-bound, high-bound, single-value, low-value, and high-value ex- 
pressions in a case-expression (Chapter 6) 

The boundary expression in an alignment-attribute (Chapter 9) 

The ctce-access-actual in a preset-attribute of a data-declaration (Chap- 
ter 9) 

The bit-count in a range-attribute of a literal- or external-literal-declara- 
tion (Chapter 9) 

The register-number in a register-declaration (Chapter 10) 

The sign-extension-flag in a field-selector (Chapter 11) 

The structure-size in the declaration of a structure-name (Chapter 11) 

The allocation-actual parameter in a structure-attribute (Chapter 11) 

The field-component in a field-declaration (Chapter 11) 

The register-number in a linkage-option (Chapter 13) 

The literal-value in a literal-declaration (Chapter 14) 

Certain parameters in lexical-functions (Chapter 15) 

The lexical-test in a lexical-conditional (Chapter 15) 
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• The compiletime-value in a compiletime-declaration (Chapter 15) 

• The level value in an OPTLEVEL module-switch (Chapter 19). 

7.1.1 Syntax 



compile-time-constant-expression 


expression 



7.1.2 Restrictions 

These restrictions apply to an expression after any macro-calls in the expres- 
sion have been expanded. 

A compile-time-constant-expression must be one of the following expressions: 

1. A numeric -literal. 

2. A string-literal. 

3. A name that 

a. Is declared in any bound-declaration except an EXTERNAL literal- 
declaration (as described in Chapter 14), and 

b. Is bound to a value that is given by a compile-time-constant-expres- 
sion. 

4. A structure-reference that yields a compile-time-constant-expression 
when it is expanded (as described in Chapter 11). 

5. A block that has a compile-time-constant-expression (and nothing else) 
as its body. 

6. An operator-expression that 

a. Is not a fetch-expression or an assignment-expression and 

b. Has a compile-time-constant-expression as each of its operands. 

7. An operator-expression that has the form: 

el { rela X e2 



( rela ) 



In these forms, rela is one of the relational operators for addresses 
(EQLA, NEQA, and so on). Both el and e2 must be link-time-constant- 
expressions; furthermore, their values must be addresses that are rela- 
tive to the same program section, external data segment, or external 
routine name. 

8. An executable-function that 

a. Is the ABS function, the SIGN function, or one of the max or min 
functions, and 

b. Has a compile-time-constant-expression as each of its parameters. 
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9. A supplementary -function that satisfies certain restrictions. Those re- 
strictions are not given here but instead appear as part of the definition 
of each supplementary-function. (For example, Section 20.2.1.1 states 
that the CH$ALLOCATION function is a compile-time-constant-ex- 
pression if its parameters are compile-time-constant-expressions.) 

10. A conditional- expression that 

a. Has a test that is a compile-time-constant-expression, and 

b. Has a consequence or alternative that is a compile-time-constant- 
expression, depending on whether the test is satisfied or fails. 

11. A case-expression that 

a. Has a case-index that is a compile-time-constant-expression, and 

b. Has at least one case-action that is a compile-time-constant-expres- 
sion; namely, that case-action that is chosen by the value of the 
case-index. 

7.1.3 Semantics 

A compile-time-constant-expression is evaluated during the compilation of 
the module in which it appears. In all other respects, its interpretation is the 
same as that for an unrestricted expression (see Chapters 4, 5, and 6). 

7.2 Link-Time Constant Expressions 

This section defines link-time-constant-expressions. The definition assumes 
the definition of expressions given in the previous chapters, and then imposes 
restrictions. The definition of link- time constant expressions includes the 
compile-time constant expressions as a special case. The restrictions on a 
link-time constant expression are designed to permit the expression to be 
evaluated by the compiler, the linker, and the operating system before the 
value is needed for program execution. 

The need for link-time constant expressions arises in two ways: 

• A name that designates storage in a program section is specified as an 
offset, not a full, absolute address, by the compiler. The absolute address 
cannot be determined until link time, when the program sections are 
allocated and their base addresses are determined. 

• A name that is declared EXTERNAL is entirely undetermined at com- 
pile time because its original declaration is in another module. Its offset, 
to say nothing of its absolute address, cannot be determined until link 
time, when the module in which the GLOBAL declaration of the name 
appears is present. 

A simple example of the use of a link-time constant expression is contained in 
the following program fragment: 

own x: vector: 10] 5 

OWN ALPHAS INITIAL(XC2] ) 5 
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During compilation, the final value of X is not known; it is expressed as an 
offset in the OWN program section. Only at link time is it possible to deter- 
mine the absolute address of X, to evaluate X[2] (the address of the third 
element of X), and, finally, to supply the initial value for ALPHA. 

Wherever the definition of BLISS requires a link- time constant expression, 
the syntactic name 

link-time-constant-expression 

is used in the appropriate syntax diagram. There are five contexts in which a 
link-time constant expression is required; they are: 

• The plit-expression in a plit (Chapter 4) 

• The plit-expression in an initial-attribute of an own- or global-declaration 
(Chapter 9) 

• The preset-value in a preset-attribute of an own- or global-declaration 
(Chapter 9) 

• The data-name-value in a GLOBAL bind-data-declaration (Chapter 14) 

• The routine-name-value in a GLOBAL bind-routine-declaration (Chap- 
ter 14). 

7.2.1 Syntax 



link-time-constant-expression 


expression 



7.2.2 Restrictions 

These restrictions apply to an expression after any macro-calls in the expres- 
sion have been expanded. 

A link-time-constant-expression must be one of the following expressions: 

1. A compile-time-constant-expression. 

2. A plit. 

3. A name that is declared as one of the following: 

a. OWN, GLOBAL, EXTERNAL, or FORWARD. (These are used for 
names of permanently allocated data segments.) 

b. ROUTINE, GLOBAL ROUTINE, EXTERNAL ROUTINE or FOR- 
WARD ROUTINE. (These are used for names of routine segments.) 

c. EXTERNAL LITERAL. (This is used for names of literals that are 
bound in other modules.) 

4. A name that 

a. Is declared by a bound-declaration (as described in Chapter 14), and 

b. Is bound to a value that is given by a link-time-constant-expression. 
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5. A structure-reference that yields a link-time-constant-expression when 
it is expanded (as described in Chapter 11). 

6. A block that has a link-time-constant-expression (and nothing else) as 
its body. 

7. An operator-expression that has the form: 

el { - } e2 

In these forms, el must be a link-time-constant-expression and e2 must 
-be a compile-time-constant-expression. 

8. An operator-expression that has the form: 

el { rela J e2 

In these forms, rela is one of the relational operators for addresses 
(EQLA, NEQA, and so on). Both el and e2 must be link-time-constant- 
expressions; furthermore, their values must be addresses that are rela- 
tive to the same program section, external data segment, or external 
routine name. 

9. A supplementary -function that satisfies certain restrictions. Those re- 
strictions are not given here but appear as part of the definition of each 
supplementary function. (For example, Section 20.2.2.1 states that the 
CH$PTR function is a link-time-constant-expression if its first parame- 
ter is a link-time-constant-expression and its remaining parameters are 
compile-time-constant-expressions.) 

7.2.3 Semantics 

A link-time-constant-expression is evaluated during the compilation, linking, 
and loading of the module in which it appears. In all other respects, its 
interpretation is the same as that for an unrestricted expression (see Chapters 
4, 5, and 6). 

The restrictions presented above seem complicated, but they express the fol- 
lowing simple idea: 

A link-time-constant-expression is 

Any compile-time-constant-expression, 

A data segment name or external name, 



• 



• 



• A data segment name or external name modified by adding or subtracting 
a constant value (using + and -), or 

• The result of comparing or taking the difference of two link-time-con- 
stant-expressions that represent addresses in the same program section or 
relative to the same external name (using the relational operators for 
addresses). 
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Chapter 8 

Blocks and Declarations 



Blocks and declarations are the fundamental structural features of BLISS. 
They are interdependent and complementary. A block is used to gather a 
sequence of declarations and expressions into a single construct. In contrast, a 
declaration is used to distribute a single set of information to many places in a 
block: To each place where the declared name is used. 

This chapter has two sections. One describes blocks, and the other describes 
declarations at the most general level. Later chapters describe the specific 
types of declarations in detail. 



8.1 Blocks 



On the inside, a block can contain a long and complicated sequence of decla- 
rations and expressions. From the outside, that same block is a single syntac- 
tic unit that has a single value. In this way, blocks provide for the large-scale 
structuring of a program. 

Blocks need not be complicated. They are often used to specify the order in 
which operators are to be evaluated; for example: 

2*( ,A-1 ) 

In this expression, "(.A-l)" is a block. It is used to show that the difference of 
.A and 1 should be calculated before multiplication by 2. This block is the 
simplest kind of block, a parenthesized-expression. 

In some cases, a block is used to gather several expressions together so that 
they are evaluated as a unit; for example: 

IF .ALPHA NEO 
THEN 

BEGIN 

01 = .ALPHA*, SI? 

02 = .ALPHA*. S25 
END? 

An equivalent way of writing this block is: 

IF .ALPHA NEO THEN (01 = .ALPHA*, SI 5 02 = . ALPHA* . S2 5 ) ! 
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The block in these examples is a compound-expression; that is, a block that 
contains one or more expressions but does not contain a declaration. The 
choice between parentheses and the BEGIN-END pair is entirely a matter of 
appearance and readability. 

Finally, a block can be used to gather together a sequence of declarations and 
expressions of arbitrary length and complexity. 

8.1.1 Syntax 



block 


( labeled-block ) 
( unlabeled-block J 


labeled-block 


{label : } ... unlabeled-block 


label 


name 


unlabeled-block 


( BEGIN block-body END ) 
\ ( block-body ) J 


block-body 


( declaration ... ) 
( nothing J 

( block-action ... ) 
( nothing J 

( block-value ) 
( nothing J 


block-action 


expression ; 


block-value 


expression 



A block immediately contains a given construct (such as a name or a declara- 
tion) if it is the smallest block that contains the given construct. 

A compound-expression is a block that does not immediately contain any 
declarations. 

A parenthesized- expression is a block that has the form: 

( expression ) 

8.1.2 Restrictions 

The label in a labeled-block must be declared by a label-declaration (see 
Section 18.4). 

A block that appears in a context that requires a value must contain a block- 
value expression. 

A block must not be empty; that is, it must contain at least one declaration, 
block-action, or block-value. 
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8.1.3 Semantics 

Consider, first, a block whose evaluation runs to completion without being 
prematurely ended by, for example, a leave-expression. The block is evalu- 
ated in three steps, as follows: 

1. Process the declarations (if any). 

2. Evaluate the block-actions (if any) in the order in which they are 
written. 

3. Evaluate the block-value expression (if any). 

If the block has a block-value expression, then the value of that expression is 
the value of the block; otherwise, the value of the block is undefined and an 
attempt to use that value is invalid. 

Most of the processing of declarations is performed before program execution 
begins. For example, the information in an OWN declaration is used by the 
compiler and linker to allocate storage, provide an initial value, and so on. In 
a few cases, the processing of a declaration requires run-time calculations. For 
example, the value in a BIND declaration can be given by an expression that 
must be evaluated each time the block is entered. 

The evaluation of block-actions in order, one after another, is the basis for 
sequential flow of control. It is valid to assume that the evaluation of a block- 
action is completed before the evaluation of the next block-action begins. In 
the course of optimization, the compiler alters the order of some calculations, 
but never in a way that affects the results. 

In BLISS the block-action plays a role similar to the role of the "statement" 
in other high level languages. The semicolon at the end of a block-action has 
the syntactic role of separating the block-action from the next component of 
the block. In addition, it has the semantic effect of discarding the value of the 
expression. Thus it is valid to use an expression whose value is undefined as 
the expression in a block-action. 

Consider, next, a block that does not run to completion. Such a situation 
arises because of a return-expression, leave-expression, or exitloop-expression 
that is contained in the block. In this situation, the value of the block is the 
value supplied by the return-expression, leave-expression, or exitloop-expres- 
sion. If no value is supplied, then the value of the block is undefined. 

8.1.4 Discussion 

An example of a block is contained in the following conditional-expression: 

IF «Q EOL 
THEN 

BEGIN 

LOCAL 

TEMP? 

TEMP = ,Xi 

X = ♦ Y 5 

Y = .TEMP? 

end; 
The block is evaluated if the contents of Q is 0. 
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The block in this example begins with one declaration, continues with three 
block-actions, and does not contain a block-value expression. The declaration 
describes a data segment named TEMP, which is allocated for use in this 
block only. The block actions are all assignments; they exchange the contents 
of X and Y. Clearly, it is important, in this example, that the assignments are 
performed in the order written. 

The entire example is an expression (a conditional-expression) followed by a 
semicolon. Therefore it is a block-action and is part of some larger block (not 
shown). 



8.2 Declarations 



A declaration provides information about the block that contains it. Usually, 
the information affects the interpretation of one or more names that are used 
in the block. Thus, although the declaration does not directly cause any 
action, it does affect the interpretation of the block by specifying information 
about the names that are declared. 

In the simplest case, the information provided by a declaration is just a single 
keyword; for example, 

OWN 

x; 

specifies that X is an OWN name. 

Sometimes a declaration gives some of the attributes that are described in 
Chapter 9. For example, 

GLOBAL 

DELTA: VECTOR C 120] INITIAL (REP 120 OF ( - 1 ) ) ", 

specifies that DELTA is a GLOBAL name and that it has the given structure- 
and initial-attributes. 

In other cases, a declaration can give even more information. For example, 

GLOBAL ROUTINE EXCH(X,Y); NOOALUE = 
BEGIN 

LOCAL TEMP5 
TEMP = . . Xi 
♦ X = ♦ • Y ; 

♦y = .temp; 
end; 

specifies that EXCH is a global routine-name, that it has the novalue-attrib- 
ute, that it has the formal-name list (X,Y), and that it designates the routine 
given in the BEGIN-END block. 

A declaration applies to those occurrences of a name that are within its scope. 
In the example just given, the declaration 

LOCAL TEMP5 

applies only to the occurrences of TEMP within the BEGIN-END block. The 
example is part of a module (not shown) but any other use of TEMP in that 
module lies outside the scope of the local-declaration in the example. 
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8.2.1 Syntax 



declaration 


/ data-declaration \ 
J structure-declaration 1 
j field-declaration 1 
1 routine-declaration I 
I linkage-declaration / 
\ enable-declaration / 
1 bound-declaration [ 
/ compiletime-declaration \ 
\ macro-declaration / 
J require-declaration 1 
J library-declaration 1 
/ psect-declaration 1 
I switches-declaration 1 
1 label-declaration 1 
1 builtin-declaration 1 
\ undeclare-declaration / 



The syntax diagrams for the specific kinds of declarations are given in later 
chapters. With few exceptions, however, each kind of declaration declares a 
user-chosen symbol as a specific kind of name (data-segment name, structure- 
definition name, routine name, etc.), and generally provides additional infor- 
mation about that name. 

A given name can be used more than once in a module and can have different 
declarations in different places. The declaration that applies to a given use of 
a name governs that name. To find the declaration that governs a given use of 
a name, proceed as follows: 

Start at the given use of the name and scan backwards through the module. 
If the end of a block is encountered, skip over everything contained in that 
block. The first declaration of the given name that is encountered during 
this scan is the desired declaration. 

One declaration of a name can govern many uses of the name. The part of a 
module that is governed by a declaration is the scope of that declaration. 

8.2.2 Restrictions 

Every use of a name must be governed by an explicit declaration. The prede- 
clared names (see Appendix A) are an exception to this rule; they can be used 
without being explicitly declared. 

Two declarations of the same name must not be immediately contained in the 
same block. 

The two restrictions just given are subject to some exceptions when UNDE- 
CLARE declarations are used (see Chapter 18). 

A name is declared as global when its declaration begins with the keyword 
GLOBAL. A name must not be declared global more than once in a program. 
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8.2.3 Semantics 

A declaration supplies the following information about each occurrence of a 
name that it governs: 

1. The one or more keywords with which the declaration begins. 

2. The attributes that appear in the declaration of the name. 

3. Other, specialized, information that is included in certain kinds of dec- 
laration, such as the routine-body in a routine-declaration, or the 
bound-value in a bind-declaration. 

Most of the information supplied by the declaration is processed by the com- 
piler. For most declarations, part of the processing defines a value for the 
declared name. For example, when an own-declaration is processed, an ad- 
dress offset is associated with the name, and that address-offset is bound (by 
the linker) to the address of a data segment. 

8.2.4 Discussion 

As defined in Section 8.2.1, the scope of a declaration is the part of a module 
that is governed by the declaration. An example of scopes is given in the 
following diagram: 



BEGIN 

OWN 

)•( t 
Y t 

Z °i 

ROUTINE SI 



BEGIN 
LOCAL 

X t 

A i 

.♦.(Calculation » 1 ) 

END ; 



, . . (Calculatio n # 2 ) 



BEGIN 

MACRO Y = '*. i 

...(Calculation »3) 

END 



..♦(Calculation #U ) 
END 



Block A 



Block B 



Block C 
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The three blocks in this example are enclosed in boxes that are identified as 
A, B, and C for convenience of discussion. Block A designates the entire 
example (including the contents of Block B and Block C). The details of the 
calculations performed by the example block are not important, so they are 
omitted. The places where names could be used in calculations are called 
Calculation #1, Calculation #2, and so on. 

The example contains seven declarations of names. The scopes of the declara- 
tions are: 



Declaration 



X 

Y 
Z 

Si 
X 
A 
Y 



(in Block A) 
(in Block A) 
(in Block A) 
(in Block A) 
(in Block B) 
(in Block B) 
(in Block C) 



Scope of Declaration 

Block A except Block B 

Block A except Block C 

Block A 

Block A 

Block B 

Block B 

Block C 



Another way to express this information is to show the declaration that 
governs each name in each of the calculations, as follows: 



Use of Name 

In Calculation #1 

X 

Y 

Z 

SI 

A 
In Calculation #2 

X 

Y 

Z 

SI 

A 

In Calculation #3 
X 
Y 
Z 
SI 
A 

In Calculation #4 



Declaration of Name 



LOCAL 


(Block B) 


OWN 


(Block A) 


OWN 


(Block A) 


ROUTINE 


(Block A) 


LOCAL 


(Block B) 


OWN 


(Block A) 


OWN 


(Block A) 


OWN 


(Block A) 


ROUTINE 


(Block A) 


(undeclared) 




OWN 


(Block A) 


MACRO 


(Block C) 


OWN 


(Block A) 


ROUTINE 


(Block A) 


(undeclared) 





(Same as in Calculation #2) 
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A second example of scope is: 



BEGIN 

OWN 

X , 
Yi 

ROUTINE B2 
ROUTINE S3 



( X ) = ♦ X + 15 



( X , Y , N ) 



BEGIN 
MAP 

Y: REF VECTOR! 

♦ x = o ; 

DECR I FROM ,N TO DO 



. . X + , Y [ . I ] 5 



end; 



END 



Block A 



Block B 



Block C 



Block D 



Block E 



The blocks in this example are labeled in the same way as in the previous 
example. Three of the blocks are implicit; that is, they are assumed to exist 
even though a BEGIN-END or parenthesis pair is not used. Specifically, 
Blocks B and C are the implicit blocks that each surround the formal-names 
and the routine-body of a routine-declaration. Block E is the implicit block 
that surrounds the body of a loop. 

This example contains ten declarations. Five of the declarations are implicit. 
Specifically, the formal-name X is implicitly declared in Block B; the formal- 
names X, Y, and N are implicitly declared in Block C; and the loop-index I is 
implicitly declared in Block E. The scopes of the declarations are: 



Declaration 


Scope of Declaration 


X ( 


in Block A) 


Block A except Blocks B and C 


Y ( 


in Block A) 


Block A except Block C 


S2 ( 


in Block A) 


Block A 


X ( 


in Block B) 


Block B 


S3 ( 


in Block A) 


Block A 


X ( 


in Block C) 


Block C 


Y ( 


in Block C) 


Block C except Block D 


N ( 


in Block C) 


Block C 


Y ( 


in Block D) 


Block D 


I ( 


in Block E) 


Block E 



Unlike all other declarations, the MAP declaration redeclares a name; that is, 
it establishes a new set of attributes to be used with a previously declared 
data segment name. Thus, the two declarations of Y in Blocks C and D refer 
to the same data segment. 
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Chapter 9 
Attributes 



Many declarations are used to associate attributes with a declared name, as 
well as declaring the name to be of a specific kind. Some attributes are 
common to many forms of declarations, and some apply to only a few forms. 
This chapter describes the attributes themselves. 

The following syntax diagram lists the attributes: 





/ allocation-unit > 


, <= 16/32 




I extension-attribute 


<= 16/32 




1 structure-attribute 






1 field-attribute j 






1 alignment-attribute 1 


<= 16/32 




1 initial-attribute 1 




attribute 


/ preset-attribute * 
\ psect-allocation / 
I volatile-attribute 1 
1 novalue-attribute 1 
1 linkage-attribute 
I range-attribute ' 






1 address-mode-attribute 


| <= 16/32 Only 




\ weak-attribute / 


1 <= 32 Only 



Each attribute is described in a section of this chapter. A final section sum- 
marizes the usage of attributes by showing which attribute can be used with 
which kind of declaration. 

9.1 The Allocation-Unit — BLISS-16/32 Only 

An allocation-unit can be used in a data-declaration or a bind-data-declara- 
tion. An allocation-unit can appear either as an independent attribute or as 
an allocation-actual parameter within a structure-attribute (as described in 
Chapter 11). 

An allocation-unit is used wherever the "granularity" of storage allocation 
must be specified. 
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Examples of the use of allocation-units in the declaration of names are: 



OWN 



A: WORD; 



A is a scalar data segment composed of one 
word (16 bits). 



global B is a vector data segment composed of ten 

b : v e c t o R c i o t B y t e ] > one-byte elements. 



LOCAL 
C i 



C is a scalar data segment composed (by 
default) of one fullword. 



9.1.1 Syntax 



16/32 Only => 








( LONG ) 


<= 32 Only 


allocation-unit 


\ WORD S 
( BYTE ) 





9.1.2 Default 

The default allocation-unit is WORD for BLISS-16, and LONG for 
BLISS-32. 



9.1.3 Restriction 

As shown in the syntax diagram, the allocation-unit LONG is valid for 
BLISS-32 only. 

An allocation-unit (used as an attribute) must not be used in the same decla- 
ration as a structure-attribute. 

If a declaration contains both an allocation-unit (used as an attribute) and an 
initial-attribute, then the allocation-unit must precede the initial-attribute. 

9.1.4 Semantics 

An allocation-unit specifies a quantity of storage, as follows: 



LONG 


32 bits 


WORD 


16 bits 


BYTE 


8 bits 



If the declaration of a name does not contain a structure-attribute (and is 
therefore a scalar declaration), the allocation-unit determines the quantity of 
storage allocated for the entire data segment. If the declaration has a struc- 
ture-attribute, the attribute can include an allocation-unit as one of its alloca- 
tion-actuals. 
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9.2 The Extension-Attribute — BLISS-16/32 Only 

Like an allocation-unit, an extension-unit can be used in a data-declaration or 
a bind-data-declaration. An extension-attribute can appear either as an inde- 
pendent attribute or as an allocation-actual within a structure-attribute (as 
described in Chapter 11). 

Examples of the use of an extension-attribute are: 

OWN 



A: SIGNED WORD 5 

GLOBAL 

B: VECTOR C 10 »BYTE »SIGNED3 5 

LOCAL 

Cs UNSIGNED BYTE 5 



A is a scalar data segment composed 
of one signed word. 

B is a vector data segment composed 
of 10 signed bytes. 

C is a scalar segment composed of 
one unsigned byte. 



9.2.1 Syntax 



16/32 Only => 
extension-attribute 



SIGNED 
UNSIGNED 



9.2.2 Restriction 

An extension-attribute (used as an attribute) must not appear in the same 
declaration as a structure-attribute. 



9.2.3 Default 

The default extension-attribute is UNSIGNED. 

9.2.4 Semantics 

An extension-attribute specifies the value extension rule to use when fetching 
the contents of a scalar field value. SIGNED specifies that the high order bit 
of the fetched value (the sign bit) is to be used. UNSIGNED specifies that 
zero bits are to be used. 

The extension-attribute is normally specified in combination with the alloca- 
tion-unit BYTE in BLISS-16, and with BYTE or WORD in BLISS-32. 



9.3 The Structure-Attribute 



A structure-attribute can be used in a data-declaration or a bind-data-decla- 
ration. It associates the declared data-segment name to a separately declared 
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structure-definition, causing the allocation of the data-segment to be con- 
trolled by that structure-definition. Subsequent access to the data-segment is 
also controlled by the associated structure-definition. (A structure-definition 
is declared in a structure-declaration. BLISS provides several predeclared 
structure-definitions, as described in Chapter 11.) 

An example of the use of a structure-attribute is: 

OWN 

X: VECTOR [8]! 

The structure-attribute here is VECTOR[8]. The attribute specifies that X is 
a data-segment with a VECTOR structure. The predeclared structure-defini- 
tion named VECTOR is described in Section 11.9. In accordance with that 
definition plus the allocation-actual, 8, specified in the attribute, X is allo- 
cated as a sequence of eight fullword elements that are designated X[0] 
through X[7]. (In BLISS-16 or BLISS-32, an allocation-unit can be used as an 
additional allocation-actual, e.g., VECTOR[8,BYTE], to specify the size of 
the elements allocated.) 

A structure-attribute can name a user declared structure-definition as well as 
one of the standard, predeclared structures described in Chapter 11. In any 
case, the interpretation of the structure-attribute depends entirely on the 
structure-declaration that governs the given structure-name. 

As an example: 

GLOBAL 

Y: matrix: 10]; 

The structure-attribute here is MATRIX[10]. The attribute specifies that Y is 
a MATRIX structure. BLISS does not have a predeclaration for the name 
MATRIX; therefore, this example must occur in the scope of an explicit 
STRUCTURE declaration of MATRIX. The interpretation of the example 
depends entirely on that STRUCTURE declaration. 

The structure-attribute is fully described in Chapter 11, together with the 
structure-declaration. 



9.4 The Field-Attribute 



A field-attribute can be used in data-declarations and bind-data-declarations. 
It specifies one or more field-names that are to be associated with the declared 
data-segment-name. This association allows the field-names to be used in 
structure-references to the data segment, as described in Chapter 11. (The 
field-attribute is meaningful only in declarations of structured data seg- 
ments.) 

The definition of a field-name, in terms of field-component values, is given in 
a field-declaration that governs the use of that name. Field-declarations are 
also described in Chapter 11. 

As a "shorthand" notational convenience, a group of field-name definitions 
can be identified (in the field-declaration) by a field-set-name and can then 
be referred to in a field-attribute by that single name. 
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9.4.1 Syntax 



field -attribute 


FIELD ( i ^Id-name ) ? } 
( field-set-name J 


field-name ) 
field-set-name ) 


name 



9.4.2 Default 

If a field-attribute is not specified for a data-segment-name, no field-names 
may appear in an ordinary-structure-reference to the corresponding data seg- 
ment. 

9.4.3 Semantics 

A field-attribute specifies the set of field-names that can validly appear in an 
ordinary-structure-reference to a data segment declared with the given field- 
attribute. A field-set-name in a field-attribute specifies a set of field-names 
that can so appear. If no field-attribute is given, then no field-name is valid in 
such a reference. 

9.5 The Alignment-Attribute — BLISS-16/32 Only 

An alignment-attribute can be used in an OWN, GLOBAL, LOCAL, or 
STACKLOCAL data-declaration. In BLISS-32, an alignment-attribute can 
also be used in a psect-declaration, as described in Section 18.1.1. This attrib- 
ute indicates the address alignment required for a data segment relative to the 
different levels of address boundaries (e.g., byte, word, longword, quadword). 

The purpose of the alignment-attribute is to specify the 'smallest' boundary 
at which the data segment may be allocated, generally a 'larger' boundary 
than the default one. For example, an alignment-attribute might be used to 
specify that a particular byte-scalar segment is to start at a word boundary 
only, rather than at any byte boundary which is the default. Use of this 
attribute can result in unused storage left between tne previously allocated 
data segment and the data segment to which the attribute applies. 

The alignment-attribute indicates a particular address boundary by means of 
a boundary value, n, which specifies that the binary address of the data 
segment must end in at least n O's. For example: 

OWN 

AsBYTE ALIGN( 1 ) 5 

The alignment-attribute, ALIGN(l), specifies that data-segment A is to be 
allocated at an address that ends with at least one 0; which is to say that it is 
to be aligned to a word boundary. 

An example of BLISS-32 usage of the alignment-attribute is given in Section 
9.5.5. 
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9.5.1 Syntax 



16/32 Only => 
alignment-attribute 


ALIGN ( boundary ) 


boundary 


compile-time-constant-expression 



9.5.2 Restrictions 

The value of boundary must be a positive integer. 

BLISS-16 ONLY 

The value of boundary must be either or 1, corresponding to byte- or 
word-boundary alignment respectively. 

The value of boundary must not exceed the value of the program-section 
alignment boundary for the storage class being allocated. 

The value of boundary in a LOCAL or STACKLOCAL declaration must not 
exceed 2. 



9.5.3 Default 

The default alignment depends on the kind of data that is declared, as fol- 
lows: 

Kind of Data Default Alignment 



BYTE scalar 
WORD scalar 
LONG scalar 
Any structure 
Any structure 



ALIGN(O) 
ALIGN(l) 
ALIGN(2) 
ALIGN(l) 
ALIGN(2) 



<= 32 Only 
<= 16 Only 

<= 32 Only 



9.5.4 Semantics 

Suppose the value of the boundary expression is n. The compiler allocates the 
declared data segment in the unused portion of the appropriate program 
section at the smallest possible address offset that ends with at least n zero 
bits. 



9.5.5 Discussion 

The alignment-attribute is a nontransportable feature, is not required for 
most purposes, and should only be used with a thorough knowledge of the 
target system's storage organization and accessing mechanisms. 

A data segment declared as OWN or GLOBAL is allocated in the appropriate 
OWN or GLOBAL program section. Its location is defined in terms of an 
address offset, that is, an address relative to the beginning of the program 
section. In BLISS-16 and BLISS-32, any address constitutes the boundary of 
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one or more allocation units: Thus all addresses are byte boundaries, every 
other address (relative to zero) is a word boundary as well, and in BLISS-32 
every fourth address is also a longword boundary, and so on. 

By default, a data segment is allocated at an address offset that is "natural" 
for either its size or type, e.g., a word-size scalar is aligned to a word bound- 
ary, and a structured segment is always fullword aligned, whatever its alloca- 
tion unit. 

In BLISS-16, where the value of boundary may be or 1, the only meaningful 
use of the alignment-attribute is to force byte-size scalar items to a word 
boundary, presumably for reasons of execution efficiency in special situations. 

In BLISS-32 the boundary value for OWN and GLOBAL data segments is 
limited only by physical-storage considerations. Further, the alignment- 
attribute can be used to specify a smaller as well as a larger boundary than 
the default (except for byte items, obviously), essentially for purposes of stor- 
age compaction versus execution efficiency. 

A data segment declared in a LOCAL or STACKLOCAL declaration is allo- 
cated in the current stackframe. The stack handling mechanism imposes 
certain restrictions such that the alignment specified for a LOCAL or 
STACKLOCAL data segment cannot exceed a longword boundary in 
BLISS-32. 

An example of the use of an alignment-attribute in BLISS-32 is: 

ONN 

X: ALIGN* 3) 5 

In this example the alignment-attribute, ALIGN(3), directs the compiler to 
allocate data-segment X in such a way that its binary address offset ends in at 
least three O's. That is to say, it directs the compiler to align the segment to a 
quadword boundary. Depending on where available storage begins, the com- 
piler must leave from zero to seven bytes of unused storage in order to satisfy 
this alignment attribute. 



9.6 The Initial-Attribute 



An initial-attribute can be used in an OWN, LOCAL, STACKLOCAL, 
REGISTER, GLOBAL-REGISTER, EXTERNAL-REGISTER, or GLOBAL 
data-declaration. 

An initial-attribute supplies one or more initialization values, which are as- 
signed to the data segment before program execution begins. 

Examples of the use of initial-attributes are: 

onn X: iimitial(2) 5 X is initialized to 2. 

global Y: uectorcg] Each element of Y is initialized 

INITIAL(REP S OF (-1))! to -1. 

16/32 Only => 

global Z: vector c 20 .byte 3 The first 4 bytes of Z are initial- 

initial(BYTE( 'stop' » ized to S, T, O, and P; the last 

rep ig of (0)))» 16 bytes to 0. 
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9.6.1 Syntax 



initial-attribute 


INITIAL ( initial-item ,... ) 


initial-item 


( initial -group \ 
< initial-expression > 
V initial-string ) 


initial-group 


t allocation-unit \ 
I REP replicator OF > 
( REP replicator OF allocation-unit / 

( initial-item ,... ) 


<= 16/32 
<- 16/32 


16/32 Only =-■> 
allocation-unit 


( LONG ) <= 32 Only 
\ WORD S 
( BYTE ) 


replicator 


compile-time-constant-expression 


initial-expression 


expression* 


initial-string 


string-literal 



* The initial-item may be an executable expression; but it is restricted in use 
to a link-time-constant-expression for OWN and GLOBAL declarations. For 
LOCAL, STACKLOCAL, REGISTER, GLOBAL REGISTER, and 
EXTERNAL REGISTER declarations, the initial-item may be an executable 

expression. 

9.6.2 Restriction 

The initial-item value(s) must not occupy more storage than is allocated for 
the data segment. 

If a declaration contains both a structure-attribute and an initial-attribute, 
then the structure-attribute must precede the initial-attribute. 

If a declaration contains both an allocation-unit (used as an attribute) and an 
initial-attribute, then the allocation-unit must precede the initial-attribute. 
(BLISS-16/32 only.) 

9.6.3 Default 

BLISS-16/32 ONLY 

If an initial-attribute appears in the declaration of a scalar name without a 
structure-attribute being present, the default allocation-unit for the initial- 
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items in the initial-attribute is the allocation-unit of the scalar name. Oth- 
erwise (without a structure-attribute), the default allocation-unit is WORD 
for BLISS-16 and LONG for BLISS -32. 

9.6.4 Semantics 

With the exception of the case where a LOCAL declaration is handling a non- 
plit item, the list of initial-items is evaluated as it would be in a plit. The 
resulting value(s) is placed in the data segment at the time it is allocated. If 
the initial-item(s) occupies less storage than the data segment, the trailing 
bits of the data segment are initialized to zeros. 

9.6.5 Pragmatics 

The use of the INITIAL attribute is the preferred method for initializing 
scalar data segments, while the use of the PRESET attribute (as described in 
Section 9.7) is the best method for initializing structured storage. 



9.7 The Preset-Attribute 



A preset-attribute can be used in an OWN, LOCAL, STACKLOCAL, REGIS- 
TER, GLOBAL-REGISTER, EXTERNAL-REGISTER, or GLOBAL data- 
declaration that declares a structured data-segment. It allows static initializa- 
tion of individual fields of a structured data-segment. 

A preset-attribute supplies an initialization value for one or more fields of a 
data structure, one value per specified field. These values are assigned to the 
data segment before program execution begins. Unspecified portions of the 
data segment are set to zero. 

An example of the use of PRESET is given in the following program fragment, 
involving a block structure defined with field-names: 

FIELD LINK_LIST_ITEMS = 
BET 

LL-VALUE = CO »0 ♦/f.BPVAL/2 tO] » 

LL-TYPE = CO >7.BPVAL/2 >'*.BPVAL/2 .• ] , 

LL_LAST = CI »0 j'XBPVAL tO] » 

LL_NEXT = C2 »0 »'Jf.BPVAL »0] 
TES ; 

GLOBAL LLIST_HEAD : BLOCK C 3] F IELD < LINK_L I ST_ ITEMS ) 

PRESET( CLL-NEXT] = LLIST_HEAD» 

CLL._LAST] = LLIST_HEAD, 

CLL-OALUE] = -1 ) ? 

In this example the origin block of a linked list is initialized with suitable 

values; note that the list of preset values is order independent. The LL 

TYPE field is set to zero by default. (The predeclared literal %BPVAL used in 
the example is defined in Section 14.1.5.) 
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9.7.1 Syntax 



preset-attribute 


PRESET ( preset-item ,... ) 


preset-item 


[ ctce-access-actual ,... ] = preset-value 


ctce-access-actual 


( compile-time-constant-expression ) 
( field-name J 


preset-value 


expression* 



* For OWN and GLOBAL declarations the preset-value must be a link-time- 
constant-expression. For LOCAL, STACKLOCAL, REGISTER, GLOBAL 
REGISTER, and EXTERNAL REGISTER declarations the preset-value may 
be an executable expression. 

The field-name is defined in Chapter 11. 

9.7.2 Restriction 

Within the declaration (OWN, LOCAL, etc.), the preset-attribute must be 
preceded by a structure-attribute. 

If any preset-item contains a field-name, the preset-attribute must be pre- 
ceded by a field-attribute designating that field-name. 

The preset-attribute and initial-attribute may not be used in the same decla- 
ration. 

A declaration may not contain more than one preset-attribute. 

The preset value(s) must not occupy more storage than is allocated for the 
data segment, and the fields described by the preset-items may not overlap. 

When expanded, the structure-reference formed by concatenating the declara- 
tion name with the bracketed access-actual list of a preset-item must only 
yield a link-time-constant-expression for an OWN or GLOBAL declaration. 
The value of that expression must be within the range of addresses allocated 
to the data-segment. Also, if that expression is a field -reference, it must 
conform to the dialect-specific restrictions on field-references used in an as- 
signment context, as specified in Section 11.2. (See the Pragmatics subsection 
below.) 

9.7.3 Default 

When a preset-attribute appears in one of the declarations, any portion of the 
segment not described by a preset-item is set to zeros upon allocation. 

9.7.4 Semantics 

The declaration name (OWN, LOCAL, etc.) is concatenated with each preset- 
item, in turn, and the expression(s) so formed are evaluated as if they were 
assignment expressions. The resulting value(s) are placed in the data segment 
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at the time it is allocated. Any portions of the data-segment not explicitly 
initialized by preset-items are set to zeros. 

9.7.5 Pragmatics 

The use of the PRESET attribute is the preferred method for initializing I 
nonscalar data-segments, although some simple VECTOR-type structures 
can be initialized conveniently with the INITIAL attribute. Initialization of 
most heterogenous structures with the INITIAL attribute is, however, imprac- I 
tical or at least an error-prone practice. 

Note that a psect-allocation attribute can be used to conveniently assign an 
initialized data-segment to write-protected storage; see Section 9.8. 

The restrictions placed on the access-actual list of the preset-item (Section 
9.7.2) seem complicated, but they simply reflect the fact that assignment- 
expressions involving a structure-reference as their left operand are, in effect, 
evaluated during the initialization process and must meet the following condi- 
tions: 

1. Must be resolvable at link time for an OWN or GLOBAL declaration. I 

2. Must result only in stores to locations allocated to the named data- 
segment (with no spillover), and 

3. Must result in assignments that are valid for the intended target sys- 
tem(s), in terms of field size and word-boundary constraints (if any). 
For example, in all dialects a field to be stored into (or fetched from) 
may not be longer than a full word. 

The specific restrictions on field-references (the typical result of structure- 
reference expansions) are fully described in Chapter 11. 

These restriction come into play only in the case of a relatively complicated or 
'tricky' structure, such as one whose definition contains a routine call or 
performs bounds checking, for example. They pose no problem for the initiali- 
zation of predeclared structures and other comparably straightforward user- 
declared structures. 
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9.8 The Psect-Allocation Attribute 

The psect-allocation attribute can be used in declarations of permanent data- 
segments and in declarations of routines. It specifies the name of the program 
section in which the declared data-segment or routine (code segment) is to be 
allocated. Program sections and the psect-declaration are described in Chap- 
ter 18. 

The psect-allocation attribute provides a more convenient means of making 
program-section assignments for OWN, GLOBAL, and code segments than is 
possible using the psect-declaration alone. A major use of the psect-allocation 
attribute is for assigning an OWN or GLOBAL data-segment to write-pro- 
tected storage. For example: 



DUMPER 



GLOBAL LITERAL 




MAIN-POWER = 0» AUK-POWER = 1» 


PRIMARY-BYPASS 


VALME-i = 3t UALME-2 = 4» SECOND-BYPASS = 5, 


OFF = f ON = 1 5 




GLOBAL STARTUP-STATE : B I TVECTOR C 7 3 


PSECT( $PLIT$ 


PRESET ( [MAIN-POWER] 


ON » 


[AUK-POWER] 


OFF t 


C VALVE- 1] 


ON » 


CMALME-2 3 


OFF t 


[PRIMARY-BYPASS] = 


OFF t 


[SECOND-BYPASS] 


ON , 


[DUMPER] 


OFF ) ; 



This fragment of a supposed process-control program establishes a control 
table of symbolically-named binary values for use by several modules and, 
since its content should never be modified, it is allocated in the $PLIT$ 
program-section, by means of the PSECT attribute. "$PLIT$" names the 
default program section for plit storage, which is given read-only access pro- 
tection (if available on a given target system). 

9.8.1 Syntax 



psect-allocation 


PSECT ( psect-name ) 


psect-name 


name 



9.8.2 Restrictions 

The psect-allocation attribute may appear in the following data- and routine- 
declarations only: 

FORWARD, OWN, GLOBAL, EXTERNAL, 

FORWARD ROUTINE, ROUTINE, GLOBAL ROUTINE, EXTERNAL 

ROUTINE 

The psect-name specified in the attribute must either be a predeclared, de- 
fault program-section name or be explicitly declared in a psect-declaration 
prior to its use. See Section 18.1. 
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If specified in a FORWARD or FORWARD ROUTINE declaration, the psect- 
name must match the psect-name explicitly or implicitly associated with the 
controlling declaration of the data-segment or routine. 

9.8.3 Defaults 

If no psect-allocation attribute is specified, then the declared data-or code- 
segment is allocated in the program section established by the most recent 
psect-declaration for the segment's storage class (OWN, GLOBAL, or 
CODE), or in the appropriate default program section. 

9.8.4 Semantics 

In declarations other than EXTERNAL or EXTERNAL ROUTINE, the 
psect-allocation attribute causes the declared data-segment or code-segment 
to be allocated in the named program section. 

In EXTERNAL and EXTERNAL ROUTINE declarations, the psect-alloca- 
tion attribute informs the compiler that the declared segment is allocated in 
the named program section of another module (presumably), and any attrib- 
utes defined for that program section in the current module are to apply. 

9.8.5 Pragmatics 

While the psect-allocation attribute need not appear in a FORWARD or 
FORWARD ROUTINE declaration, its specification in those declarations 
can favorably affect the quality of code generated for the segment in 
question, particularly in the case of FORWARD ROUTINE. (Note that 
there is no default program-section name associated with a FORWARD or 
FORWARD ROUTINE declaration.) 

The psect-allocation attribute is essentially a convenience, allowing the pro- 
grammer to more easily achieve what would otherwise require repeated uses of 
the PSECT declaration. 



9.9 The Volatile-Attribute 



A volatile-attribute can be used in any data-declaration other than a REGIS- 
TER declaration. It can also be used in a bind-data-declaration. 

For purposes of optimization, the compiler assumes that the contents of a 
data segment will be changed during execution in either of two ways: by an 
assignment or by a routine-call. The volatile-attribute specifies that the con- 
tents of the declared data segment can change in a third way: by an action 
that is not directly specified in the module being compiled. This attribute 
causes the compiler to assume that the value in the declared data segment 
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can change at any time. Consequently the compiled code must fetch the 
contents of that data segment anew for each fetch in the BLISS program and 
must store a value for each assignment. 

An example of the use of a volatile-attribute is: 

GLOBAL INPUT_PORT: VOLATILE; 

In this example, it is assumed that INPUT PORT designates a data segment 

that is set, through an interrupt routine, whenever a fullword of input arrives. 

9.9.1 Syntax 



volatile-attribute 



VOLATILE 



9.9.2 Semantics 

A volatile attribute is a warning to the compiler that the contents of a data 
segment can change at any time. A module that does not declare each such 
data segment as VOLATILE is invalid. 

If the volatile-attribute appears in the declaration of the name of a REF 
structure (as described in Sections 11.1.3.5 and 11.4), then the volatile attrib- 
ute applies both to the storage for the address of the structure and to the 
storage for the structure itself. 



9.10 The Novalue-Attrlbute 



The novalue-attribute can be used in a routine-declaration or a bind-routine- 
declaration. It specifies that the declared routine does not return a value. 

It is usually possible to determine by inspection whether or not a routine 
returns a value. However, in order to facilitate optimization and to provide 
clear documentation, this information must be given as part of the declaration 
of the routine-name. Specifically, the novalue-attribute must or must not be 
used depending on whether the routine does not or does return a value. 

An example of a routine that does not return a value is: 

There is a NOVALUE attribute, so the 
routine does not return a value; in- 
stead, its effect is to exchange the val- 
ues of X and Y. 



ROUTINE E) 


«CH(X »Y 


: NOVALUE 


BEGIN 






LOCAL 


temp; 




TEMP = 


= . . X i 




« Y = 


TEMP ; 




END 5 
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This routine, having no RETURN expression, returns control after complete 
evaluation of the routine-body. Since the routine-body is a block that consists 
solely of block-actions (expressions terminated by a semicolon) and has no 
block-value, no value is returned. The NOVALUE attribute affirms this pro- 
cedure-like characteristic. See Section 8.1 for a discussion of block-actions 
and block-values. 

Note carefully that if routine EXCH did not contain the NOVALUE attrib- 
ute, the compiler would assume that a null expression (namely the block- 
value expression) exists between the last expression shown and the block 
terminator. This in turn would cause the compilation diagnostic "Null expres- 
sion appears in value-required context". When such a routine is called, it may 
appear to return a value, but that value is unpredictable. 

Alternatively, if the last assignment expression were not terminated by a 
semicolon (and NOVALUE was specified), the routine would indeed have a 
block-value — the value of that assignment expression. However, that value 
would be discarded prior to return of control because of the NOVALUE attrib- 
ute. Thus a routine with the NOVALUE attribute never has a return value, no 
matter what value-implying expressions appear in its body. 

9.10.1 Syntax 



novalue-attribute 



NOVALUE 



9.10.2 Restrictions 

A routine that is declared with a novalue-attribute must not be called in a 
context that requires a value. 

9.10.3 Semantics 

The value of a routine that is declared with the novalue-attribute is unde- 
fined. 



9.11 The Linkage-Attribute 



The linkage-attribute can be used in a routine-declaration or a bind-routine- 
declaration. It specifies a linkage-name that is associated with the declared 
routine-name. This, in turn, causes the routine-name to be associated with 
the linkage-declaration that governs that linkage-name. The linkage-defini- 
tion identified by the linkage-name controls both the code generated for the 
given routine and the code generated for any call to that routine. 
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A linkage is the machanism used to call a routine; it saves registers, passes 
parameters, and controls other aspects of communication between a routine- 
call and the called routine. The default linkage-name BLISS in BLISS-16/32, 
or BLISS36C in BLISS-36, identifies the standard linkage convention for 
BLISS-compiled routines. 

The linkage-attribute is simply a name; it is the declaration of that name that 
specifies the linkage to be used. BLISS includes several predeclared linkage- 
names. Linkage-declarations and predeclared linkage-names are described in 
Chapter 13. 

9.11.1 Syntax 



linkage-attribute 


linkage-name 


linkage-name 


name 



9.11.2 Restrictions 

A linkage-name must be one of the predeclared linkage-names or must be 
governed by a linkage-declaration. 

A linkage-attribute given for a routine-name in an EXTERNAL ROUTINE, 
FORWARD ROUTINE, BIND ROUTINE, or GLOBAL BIND ROUTINE 
declaration must be the same as the linkage-attribute given in the correspond- 
ing ROUTINE or GLOBAL ROUTINE declaration. 

9.11.3 Defaults 

The default linkage-attribute is the predeclared linkage-name BLISS for 
BLISS-16 or BLISS-32, and the linkage-name BLISS36C for BLISS-36. 

9.11.4 Semantics 

A linkage-attribute associates a linkage-name with a routine-name. Thus, the 
linkage-attribute indirectly controls the linkage-related code generated for a 
ROUTINE or GLOBAL ROUTINE DECLARATION, and the code generated 
for all calls to the routine, according to the definition of the specified linkage- 
name. 



9.12 The Range-Attribute 



The range-attribute can be used in a literal-declaration or external-literal- 
declaration. These declarations are described in Chapter 14. 
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A literal-name designates a constant value that is used as data but is stored in 
the object code rather than in a data segment. When the compiler is provided 
with sufficient information and the literal value is small enough, a short field 
can be generated for the value rather than a full word. 

The range-attribute specifies the quantity of storage required for a literal and 
indicates whether the field is to be interpreted as a signed or unsigned repre- 
sentation. 

An example of the use of the range-attribute is: 

EXTERNAL LITERAL Ms UNSIGNED(4)5 

The effect of this attribute in a BLISS-32/V AX- 11 context is as follows. 
(Analogous effects would be obtained on other target systems.) At the time 
the module containing this declaration is compiled, it is assumed that the 
value of X can be accomodated in a VAX-11 literal-operand specifier, and 
code is generated on that assumption. Then, when the modules are linked, a 
check is made for agreement of the range-attribute with the external value 
and the value of X is then placed in the empty fields provided for it. 

Suppose the following declaration appears in another module of the same 
program: 

GLOBAL LITERAL X = 12s UNSIGNED^)! 

This declaration not only specifies that X designates the value 12, but also 
that it can be stored as an unsigned integer in four bits. This attribute both 
documents that a range-attribute assumption exists in another module of the 
program and allows the compiler to verify that the assumption is satisfied. 

9.12.1 Syntax 



range-attribute 


( SIGNED ) ( bit . count ) 
\ UNSIGNED ] { Dlt C0Unt ' 


bit-count 


compile-time-constant-expression 



9.12.2 Restriction 

The value, n, of bit-count must be in the range 1 < n < %BPVAL. That is, the 
field specified may not be longer than a full word. 

9.12.3 Default 

The default range-attribute is SIGNED (%BPVAL). 
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9.12.4 Semantics 

The range-attribute specifies the maximum number of bits required for a 
given literal value, and indicates whether the value is to be interpreted as a 
signed or unsigned integer. 

9.13 The Addressing-Mode-Attribute — BLISS-16/32 Only 

Each data or routine name has, as its value, an address. As the compiler 
translates a BLISS module into an object module, it replaces each use of a 
data or routine name with an offset address value. The final address value is 
supplied later by the linker and the operating system. But the compiler does 
provide a sequence of bytes in the object code to accommodate the final 
address value. 

A VAX-11 address can be encoded as either absolute or relative, and in either 
a short or long form, and a PDP-11 address can be encoded as either absolute 
or relative. The addressing-mode-attribute determines the way in which the 
address is encoded. For every use of a data or routine name, the default rules 
specify an addressing-mode-attribute (if one is not given explicitly). 

An addressing-mode-attribute can be given in an OWN, GLOBAL, 
FORWARD or EXTERNAL declaration, described in Chapter 10, or in 
a ROUTINE, GLOBAL ROUTINE, FORWARD ROUTINE or 
EXTERNAL ROUTINE declaration, described in Chapter 12. This attribute 
can also be used in a PSECT declaration (Section 18.1), and in a SWITCHES 
declaration or a module-head switch (Sections 18.2 and 19.2 respectively). 
The latter two uses indirectly control a number of individual data- and/or 
routine-declarations. 



9.13.1 Syntax 



16/32 Only => 

addressing-mode- 
attribute 


ADDRESSING—MODE ( mode-16 J 

I mode-32) 


mode-16 


( ABSOLUTE ) 
\ RELATIVE J 


mode-32 


/ GENERAL \ 
1 ABSOLUTE I 
1 LONG—RELATIVE ( 
V WORD— RELATIVE / 
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9.13.2 Default 

Consider a name that is declared by one of the following declarations: 

own-declaration 

global-declaration 

forward-declaration 

external-declaration 

routine-declaration 

global-routine-declaration 

forward-routine-declaration 

external-routine-declaration 

psect-declaration 

For a name so declared, the addressing-mode-attribute is obtained by the 
following rules (in the order of their application): 

1. If a default PSECT is associated with one of these declarations, the mode 
declared in the psect is used. Thus OWN, GLOBAL, and ROUTINE 
declarations would use psect addressing modes of OWN, GLOBAL, and 
CODE, respectively (as described in Section 18.1). 

2. If the declaration type is FORWARD or FORWARD ROUTINE, the mode 
established by the ADDRESSING_MODE (NONEXTERNAL-...) mod- 
ule-head switch or the switches declaration is used (as described in Sec- 
tions 18.2 and 19.2). 

3. If the declaration type is EXTERNAL or EXTERNAL ROUTINE, the 
mode established by the ADDRESSING—MODE (EXTERN AL=...) 
module-head switch or the switches declaration is used (as described in 
Sections 18.2 and 19.2). 

If a PSECT attribute is given, the addressing mode specified in the psect is 
used (as shown in the following example): 

OWN 

X: PSECT(GEN) 

ADDRESSING_MODE( WORD RELATIVE ); 

If an ADDRESSING MODE attribute is given, the addressing mode speci- 
fied by the switch is used. If both PSECT and ADDRESSING__MODE are 
used, then the last attribute encountered determines the addressing mode. 

9.13.3 Semantics 

The compiler translates each use of a data or routine name into an encoded 
address. An encoded address consists of an encoding-type followed by a dis- 
placement. The encoding-type specifies the addressing-mode-attribute and 
other information, while the displacement is an address specification. The 
encoding-type always occupies one byte, while the displacement occupies a 
number of bytes that is determined by the addressing-mode-attribute. 
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The addressing-mode-attribute instructs the compiler in the preparation of an 
encoded address, as follows: 



Attribute 

GENERAL 



ABSOLUTE 



LONG—RELATIVE 



WORD_RELATIVE 



RELATIVE 



Instruction to Compiler 

Let the linker make the choice between using a 
relative displacement or an absolute value. Provide 
four bytes for the displacement, or value, and one 
byte for the addressing mode descriptor. 

Use an absolute value. If BLISS-32 put in four 
bytes. If BLISS-16 put in two bytes. 

Use a relative displacement, and put it in four 
bytes. 

Use a relative displacement, and put it in two 
bytes. 

Use a relative displacement, and put in two bytes. 



The RELATIVE and WORD—RELATIVE attributes apply to most names 
(each is the ultimate default for its mode), and are appropriate for references 
within executable images that are not unusually large. The LONG — RELA- 
TIVE attribute is used in the infrequent situation where 16 bits is not suffi- 
cient to represent a relative address. The ABSOLUTE attribute is used for 
names that designate addresses that are fixed in the address space, such as 
system service routines, device register addresses, and data. The GENERAL 
attribute is used when the choice between an absolute or relative address 
cannot be made at compile time. 

9.14 The Weak-Attribute — BLISS-32 Only 

The weak-attribute can be used in a declaration that has either GLOBAL or 
EXTERNAL in its keyword phrase. Such declarations are described in many 
places in the following chapters. 

The weak-attribute affects the way in which the VAX-11 linker and librarian 
programs handle global names. (This is discussed further under EXTERNAL 
declarations, in Section 10.4.3.) 



9.14.1 Syntax 



32 Only => 
weak-attribute 



WEAK 
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9.14.2 Semantics 

The weak-attribute specifies a property of a name for use by the linker and 
librarian programs, as described in the manuals for those programs. 



9.15 A Summary of Attribute Usage 

Each attribute description in this chapter includes a list of the declarations in 
which the attribute can be used. That information is gathered together in the 
following table, where an "x" marks each attribute that can be used in each 
kind of declaration. 

Allocation-Unit 
Extension 
Structure 
Field 

Alignment 
Initial 

Preset 



OWN 
GLOBAL 
FORWARD 
EXTERNAL 

LOCAL 

STACKLOCAL 
REGISTER 
GLOBAL REG. 
EXTERNAL REG. 

MAP 

BIND 
GLOBAL BIND 

ROUTINE 
GLOBAL RTN. 
FORWARD RTN. 
EXTERNAL RTN. 

BIND ROUTINE 
GLOBAL BIND RTN. 

LITERAL 
GLOBAL LIT. 
EXTERNAL LIT. 



X 



X X X X 

X X X X 

X X X X 

X X X X 



X 



X X X X 
X X X X 



t t 



X X 

X X 

X X 

X X 

X X 



Psect-Allocation 
Volatile 

Novalue 



Linkage 
Range 

Addressing-Mode 
I Weak 



V v f 



X X 

X X 

X X 

X X 

X X 

X X 



t 



X 



X 
X 
X 
X X 
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Chapter 10 

Data Declarations 



A data-declaration describes one or more data segments. Taken together, the 
data declarations of a program specify the storage required for the data on 
which that program operates. 

The data-declarations can be divided into three categories, as follows: 

• A permanent declaration begins with OWN, GLOBAL, or EXTERNAL. 
It describes a data segment that remains allocated throughout the execu- 
tion of the program. 

• A temporary declaration begins with LOCAL, STACKLOCAL, REGIS- 
TER, GLOBAL REGISTER, or EXTERNAL REGISTER. It describes a 
data segment that exists only during each execution of a given block. 

• An overlay declaration begins with MAP. It describes a data segment 
that has been declared elsewhere, but that is given new attributes by this 
declaration. 

A data-declaration provides some or all of the following information about 
each data segment it declares: 

• The name of the data segment. 

• The address of the data segment, which is determined by the kind of 
declaration and by some of the attributes. The address of the data seg- 
ment becomes the value of the declared name. 

• The scope of the name of the data segment, which depends on the posi- 
tion of the declaration within the program and on the kind of declaration. 

• The longevity of the data segment, which is determined by the kind of 
declaration (permanent or temporary). 

• The attributes of the data segment, which are given as part of the decla- 
ration and by the default rules for attributes. 

The attributes applicable to data-declarations are described in Chapter 9 
except for the structure-attribute which is described in Chapter 11 along with 
other aspects of data structures. 
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The syntax diagram for data-declarations is: 



data-declaration 


/ own-declaration \ 
1 global-declaration 1 
1 forward -declaration 1 
J external-declaration I 
\ local-declaration / 
1 stacklocal-declaration 1 
I register-declaration 1 
I map-declaration J 



10.1 Own-Declarations 



The storage for an OWN data segment is permanent; that is, it is created 
before program execution begins and exists throughout program execution. 
The scope of an own-declaration is its immediately containing block (includ- 
ing any lower-level blocks contained therein). That is to say, the name of an 
OWN data segment can be used only within the block in which it is declared. 

An example of an own-declaration in a routine-declaration context is: 

ROUTINE KILO = 
BEGIN 
OWN 

X: INITIAL (0) 5 
X = . X+i ; 

IF . X LEQ 1000 THEN 1 ELSE 
END! 

The data segment named X is allocated and initialized only once, before 
program execution begins. It can be referred to by the name X only within the 
routine KILO. 



10.1.1 Syntax 



own-declaration 


OWN own-item ,... ; 


own-item 


own-name { : own-attribute . 
( nothing 


) 




own-name 


name 




/ allocation-unit \ 


<= 16/32 Only 




I extension-attribute j 


<= 16/32 Only 




1 structure-attribute 1 






I field-attribute ( 




own-attribute 


/ alignment-attribute V 
J initial-attribute 1 
J preset-attribute 1 
1 psect-allocation 1 
V volatile-attribute / 


<= 16/32 Only 
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10.1.2 Restrictions 

BLISS-16/32 only: A structure-attribute must not appear in the same decla- 
ration as an allocation-unit or an extension-attribute. If the declaration con- 
tains both an allocation-unit attribute and an initial attribute, the allocation- 
unit must precede the initial-attribute. 

A field-attribute can appear only in a declaration that has a structure- 
attribute. 

If the declaration contains both a structure-attribute and an initial-attribute, 
the structure-attribute must precede the initial-attribute. 

If the declaration contains both a structure -attribute and a preset- attribute, 
the structure-attribute must precede the preset-attribute. 

An initial- and a preset- attribute must not appear together in the declaration. 

The declaration must not contain more than one initial- or preset-attribute. 

If the preset-attribute contains a field-name, the preset-attribute must be 
preceded by a field-attribute that designates the field-name. 

10.1.3 Semantics 

The data segment designated by a name that is declared OWN is allocated in 
the current program section for the storage class OWN, as described in Sec- 
tion 18.1. Program sections for the storage class OWN are created before 
program execution begins and are not discarded until after program execution 
is complete. 

The data segment for an OWN name is always allocated at the lowest possible 
address within the unused portion of the current OWN program section, after 
allowing for address-alignment requirements (if any). 

In BLISS-16, data segments larger than one byte are allocated at even ad- 
dresses, which may leave an unused byte preceeding the data segment. One- 
byte data segments are allocated at the next available byte. 

In BLISS-32 the address must be consistent with the alignment-attribute, 
which is either given explicitly or determined by default. The alignment- 
attribute may dictate some unused bytes, as described in Section 9.5. 

In BLISS-36 there are no special alignment rules; each data segment is allo- 
cated at the next available word. 

Because OWN data segments are allocated in this way, the address of one 
OWN data segment can be calculated relative to that of another, provided 
that both segments are declared in the same module and allocated in the 
same program section. 

When the storage for an OWN data segment is created by the linker, it is set 
to 0's. If the data segment is given an initial value in the declaration, it is 
initialized by the linker. 
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10.2 Global-Declarations 



Like an OWN data segment, the storage for a GLOBAL data segment is 
permanent; that is, it exists throughout program execution. In contrast to an 
OWN data segment, the name of a GLOBAL data segment can be used in 
several separate blocks; that is, in the block in which it is declared GLOBAL 
and in each block in which it is declared EXTERNAL. 

Usually the block in which a name is declared GLOBAL is in one module and 
the blocks in which it is declared EXTERNAL are in other modules. In this 
way, a data segment can be shared among several modules. 

Aside from the initial keyword, the syntax of the own-declaration and global- 
declaration is identical, except that in BLISS-32 the weak-attribute is per- 
mitted in a global-declaration. 

10.2.1 Syntax 



global-declaration 


GLOBAL global-item ,... ; 


global-item 


global-name I : global-attribute 
( nothing 


■-} 


global-name 


name 




/ allocation-unit \ 


<= 16/32 Only 




/ extension-attribute \ 


<= 16/32 Only 




I structure-attribute 1 






\ field-attribute / 




global-attribute 


/ alignment-attribute I 
\ initial-attribute / 
J preset-attribute y 
/ psect-allocation 1 
1 volatile-attribute J 


<= 16/32 Only 




\ weak-attribute ^ 


<= 32 Only 



10.2.2 Restrictions 

A name is declared as global when the declaration begins with the keyword 
GLOBAL (except for GLOBAL REGISTER, Section 10.8). A name must not 
be declared as global more than once in a program. 

All the attribute restrictions given in Section 10.1.2 also apply to GLOBAL 
declarations. 



10.2.3 Semantics 

The data segment designated by a name that is declared GLOBAL is allo- 
cated in the current program section for the storage class GLOBAL, as de- 
scribed in Section 18.1. Program sections for the storage class GLOBAL are 
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created before program execution begins and are not discarded until after 
program execution is complete. 

The data segment for a GLOBAL name is allocated in the same predictable 
way as the data segment for an OWN name. Therefore, a programmer can 
determine the relative addresses of any two GLOBAL data segments that are 
declared in the same module and are allocated in the same program section. 

A GLOBAL data segment can be accessed by name within the scope of the 
declaration of its name. In addition, it can be accessed within the scope of any 
external-declaration of its name. 



10.3 Forward-Declarations 



A forward-declaration is used to give the attributes of a name before storage is 
allocated for the name. A forward-declaration is always used in conjunction 
with an own-declaration or a global-declaration; it is used to avoid what 
would otherwise be a vicious circle of definitions. Such situations are unusual, 
but they do arise. 

As an example, suppose that X and Y are pointers; that is, X and Y are each 
the name of a data segment that contains the address of another data seg- 
ment. Suppose, also, that X and Y must be initialized to point to each other. 
The required declarations are: 

FORWARD 



OWN 



INITIAL(Y) t 
INITIAL (X) 5 



The forward-declaration declares Y so that it can be used to initialize X 
which, in turn, is used to initialize Y. 

10.3.1 Syntax 



forward- declaration 


FORWARD forward-item ,... ; 


forward -item 


forward-name ( : forward -attribute ... ) 
( nothing ) 


forward-name 


name 


forward-attribute 


/ allocation-unit \ <= 16/32 Only 
1 extension-attribute 1 <= 16/32 Only 
1 structure-attribute 1 
< fie Id- attribute > 
1 psect-allocation 1 
1 volatile-attribute 1 
\ addressing-mode-attribute / <= 32 Only 
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10.3.2 Restrictions 

Each name that is declared by a forward-declaration must also be declared, a 
second time, by an own-declaration or a global-declaration that is in the same 
block. 

After the default attributes have been filled in, a forward-declaration of a 
name and the associated own-declaration or global-declaration of the same 
name must be identical with respect to all of the attributes allowed in the 
forward-declaration. 

All of the attribute restrictions given in Section 10.1.2 also apply to FOR- 
WARD declarations. 



10.3.3 Semantics 

The forward-declaration associates attributes with a name without allocating 
the storage for that name. 



10.4 External-Declarations 



A name that is declared EXTERNAL is assumed to be declared GLOBAL 
somewhere else in the same program. The linker treats each occurrence of the 
name governed by an external-declaration as if it were governed by the global- 
declaration of the same name. Thus the external declaration does not cause 
the allocation of a data segment but rather extends the accessibility of a data 
segment that is allocated elsewhere. 

10.4.1 Syntax 



external-declaration 


EXTERNAL external-item ,... ; 


external-item 


external-name ( : external-attribute ... ) 
( nothing J 


external-name 


name 


external-attribute 


/ allocation-unit \ <= 16/32 Only 

1 extension-attribute 1 <= 16/32 Only 

1 structure-attribute 1 

J field-attribute I 

\ psect-allocation / 

I volatile-attribute 1 

1 addressing-mode-attribute | <= 32 Only 

I weak-attribute 1 <= 32 Only 
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10.4.2 Restrictions 

A name that is declared EXTERNAL must also be declared GLOBAL some- 
where else in the same program. In BLISS-32, this restriction does not apply 
if the EXTERNAL name has the weak-attribute. 

All of the attribute restrictions given in Section 10.1.2 also apply to EXTER- 
NAL declarations. 

After default attributes have been filled in, the following attributes of the 
EXTERNAL and GLOBAL declarations of a given name must be identical: 

allocation-unit 
extension-attribute 
structure - attribute 
field-attribute 
volatile-attribute 



10.4.3 Semantics 

The linker generates and uses a list of all names that are declared GLOBAL in 
the entire program. For each such name, the list shows the value of the name 
and some of the attributes of the name. This list is used in determining the 
value of a given EXTERNAL name as follows: 

• The list is searched for an entry for the given name. If such an entry is 
found, then it supplies the value of the given EXTERNAL name. 

• In BLISS-32 only, if no entry for the given name is found and the given 
name has the weak-attribute, then is used as the value of the given 
name. 

• If no entry for the given-name is found and the given name does not have 
the weak-attribute, then the program is not valid. 

In BLISS-32 only, when an EXTERNAL name has the value (determined 
because no entry was found and the weak-attribute was present), the program 
can be executed provided an attempt is not made to use the given name as an 
address. 

An EXTERNAL name already declared can be encountered in a GLOBAL or 
FORWARD declaration. If such a case arises, the following is done: First, 
parse the declaration. Then compare the attributes of the EXTERNAL decla- 
ration with those of the GLOBAL or FORWARD declaration; if there is a 
mismatch, generate a warning message. 



10.5 Local-Declarations 



The storage for a LOCAL data segment is temporary; that is, it exists only 
during the execution of the block in which it is declared. The data segment is 
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allocated either in the stackframe for the block in which it is declared, or in a 
general register that is free. 

The scope of a LOCAL data-declaration is its immediately containing block 
excluding any lower-level contained routines. That is, unlike OWN data seg- 
ments, "up-level" references to a LOCAL data segment from a lower-level 
routine are not permitted. 

10.5.1 Syntax 



local-declaration 


LOCAL local-item ,... ; 


local-item 


local-name { : local-attribute ... ) 
( nothing J 


local-name 


name 


local-attribute 


allocation-unit <= 16/32 Only 

extension-attribute <= 16/32 Only 

structure-attribute 

field-attribute 

alignment-attribute <= 16/32 Only 

initial-attribute 

preset-attribute 

volatile-attribute 



10.5.2 Restrictions 

A local-declaration must be contained in a routine-body. 

Suppose the routine-body of a given routine, routine A, contains the declara- 
tion of another routine, routine B. If a name is declared LOCAL in routine A 
and is not declared in routine B, then the name cannot be used in routine B. 
(Such usage would be an "up-level" reference, which is prohibited for local- 
names.) 

A program must not depend on the relative positions of two LOCAL data 
segments in storage. 

All of the attribute restrictions given in Section 10.1.2 also apply to LOCAL 
declarations. 

BLISS-32 only: An alignment-attribute used in the declaration of a LOCAL 
name must not have a boundary expression whose value is greater than 2. 

10.5.3 Semantics 

The data segment for a LOCAL name is allocated either in the current stack 
frame or in a general register. In either of the following situations, a given 
LOCAL data segment is always allocated in the current stack frame: 

• The given data segment occupies more than a full word. 
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• The name of the given data segment is used as an independent address; 
that is, its use is not confined to a fetch expression or to the left-hand-side 
of an assignment expression. 

In other situations, the choice between stack frame and register is based on 
strategies that the compiler uses for code optimization. 

10.5.4 Pragmatics 

A temporary data segment (such as a LOCAL data segment) must be used for 
a recursive variable in a recursive routine. 



10.6 Stacklocal-Declarations 



A STACKLOCAL data segment is always allocated in the current stack 
frame. In all other respects, it is the same as a LOCAL data segment. 

10.6.1 Syntax 



stacklocal-declaration 



STACKLOCAL local-item ,... ; 



The local-item is as defined in Section 10.5.1. 

10.6.2 Restrictions 

All of the attribute restrictions given in Section 10.1.2, and all the restrictions 
given in Section 10.5.2 for LOCAL data segments also apply to STACK- 
LOCAL declarations. 

10.6.3 Semantics 

The semantics given in Section 10.5.3 for LOCAL data segments apply to 
STACKLOCAL data segments except that a STACKLOCAL data segment is 
always allocated in the current stack frame. 



10.7 Register-Declarations 



A register data segment is a data segment that is always allocated in a general 
register. In most other respects, it is the same as a LOCAL data segment. If 
the declaration specifies a register-number, the data segment is allocated in 
the specified register. Otherwise, the data segment is allocated in a register 
chosen by the compiler. 

An example of a register-declaration is: 

REGISTER 

STATUS = 5s BITVECTORCIO] ♦ 
BETA 5 

This declaration associates the names STATUS and BETA with two general 
registers. The register number for STATUS is given explicitly as 5 and only 10 



Data Declarations 10-9 



bits of that register are used. The register number for BETA is left to be 
chosen by the compiler, and the full register is used. 

10.7.1 Syntax 



register-declaration 


REGISTER register-item ,... ; 


register-item 


register-name 

( = register-number ) 
( nothing J 

( : register-attribute ... ) 
( nothing J 


register-name 


name 


register-number 


compile-time-constant-expression 


register-attribute 


/ allocation-unit \ <= 16/32 Only 
1 extension-attribute 1 <= 16/32 Only 
1 structure-attribute I 
| field-attribute | 
/ initial-attribute 1 
\ preset-attribute / 



10.7.2 Restrictions' 

The value of the register-number, if specified, must be in the range given 
below for each dialect: 



For BLISS-16 
For BLISS-32 
For BLISS-36 



through 5 
through 11 

through 12, if the governing linkage-attribute is 
BLISS36C (the default), FORTRAN_FUNC, or FOR- 
TRAN—SUB. 

1 and 3 through 15, if the governing linkage-attribute is 
BLISS10 

The general rule for BLISS-36 is that the register-num- 
ber must not specify a register in use as the stack pointer, 
the frame pointer, or the argument pointer (if applica- 
ble) . The linkage-definition that governs the routine con- 
taining the register-declaration controls the assignment 
of registers for these uses. 

A register specified by register-number must be PRESERVED or NOTUSED 
in the linkage of any routine called in the containing block if the call occurs 
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within the 'useful lifetime' of the register data segment. (That is, if the call 
occurs between the first and last possible references to that segment.) 

A register data segment must not occupy more than a full word. 

A register-declaration must be contained in a routine-body. 

Suppose the routine-body of a given routine, routine A, contains the declara- 
tion of another routine, routine B. If a name is declared REGISTER in routine 
A and is not declared in routine B, then the name cannot be used in routine B. 
Such usage would be an "up-level" reference and is not permitted for register 
data segments. 

All the attribute restrictions given in Section 10.1.2 also apply to REGISTER 
declarations. 

A name declared in a register-declaration must be used only as the operand of 
a fetch expression or as the first operand of an assignment expression. (This 
restriction does not apply to certain machine-specific-function parameters; 
see the applicable BLISS User's Guide.) 

10.7.3 Semantics 

If a register-number is given in the declaration of a register data segment, 
then the data segment is allocated in that register. During execution of the 
routine that contains the declaration, the register may be used for other pur- 
poses, but none that conflict with the valid use of the allocated data segment. 

A register data segment is similar to a local data segment in that it is created 
on entry to the block in which it is declared and released on exit from that 
block, and cannot be referenced from any lower-level contained routine-body. 

10.7.4 Pragmatics 

Standard register-names with appropriate predefined values are provided, as 
builtin-names, for each BLISS dialect. In order to use these names with their 
predefined values, they may be declared in a BUILTIN declaration (Section 
18.3). The builtin register-names and values are as follows: 

FOR BLISS-16 FOR BLISS-32 

Name Value Name Value 



R0 





Rl 


1 


R2 


2 


R3 


3 


R4 


4 


R5 


5 


SP 


6 


PC 


7 



R0 





Rl 


1 


R2 


2 



Rll 


11 


AP 


12 


FP 


13 


SP 


14 


PC 


15 
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FOR BLISS-36 

The builtin register-names SP, FP, and AP are provided. The value defined 
for each name depends upon the linkage-definition associated with the 
routine in which the name is declared BUILTIN. See Chapter 13, on "Link- 
ages". 

1 0.8 Global-Register-Declarations 

A global register data segment is a data segment that is created and allocated 
in a given register in one routine, and may be made available for use in other 
routines that are called by the declaring routine. Global register data seg- 
ments are identified by name, and both the calling and called routine must 
agree (through a matching set of register- and linkage-declarations) that a 
particular global register data segment is available. 

A global register data segment is the same as an ordinary register data seg- 
ment with respect to its use within the declaring routine. 

A GLOBAL REGISTER declaration establishes the name and actual register 
assignment of a global register data segment and creates the storage (that is, 
allocates the register) . In order for the data segment to be available to a called 
routine, that routine must specify the same name in an EXTERNAL REGIS- 
TER declaration and must specify both the name and register-number in the 
GLOBAL linkage-option of its governing linkage-definition. 

10.8.1 Syntax 



global-register- 
declaration 


GLOBAL REGISTER register-item ,... ; 


register-item 


register-name 

= register-number 

( : register-attribute ... ) 
( nothing ) 


register-name 


name 


register-number 


compile-time-constant-expression 


register-attribute 


/ allocation-unit \ <= 16/32 Only 
I extension-attribute J <= 16/32 Only 
) structure-attribute \ 
\ field-attribute J 
/ initial-attribute I 
V preset-attribute / 
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10.8.2 Restrictions 

The register-number is constrained by the containing routine's linkage as 
described for ordinary register data segments in the first paragraph of Section 
10.7.2, but is also constrained by the linkage-definition governing any called 
routine that refers to the declared global register data segment. The inter- 
routine requirements are described in Chapter 13, on "Linkage Declarations." 

A register data segment must not occupy more than a full word. 

A global-register-declaration must be contained in a routine-body. 

Suppose the routine-body of a given routine, routine A, contains the declara- 
tion of another routine, routine B. If a name is declared GLOBAL REGISTER 
in routine A and is not declared in routine B, then the name cannot be used in 
routine B. Such usage would be an "up-level" reference and is not permitted 
for register data segments. 

All the attribute restrictions given in Section 10.1.2 also apply to GLOBAL- 
REGISTER declarations. 

A name declared in a global-register-declaration must be used only as the 
operand of a fetch expression or as the first operand of an assignment expres- 
sion. (This restriction does not apply to certain machine-specific-function 
parameters; see the applicable BLISS User's Guide.) 

If the linkage definition of a called routine specifies a global register data 
segment, then the routine call must be in the scope of a global- or external- 
register-declaration of the data segment. 

BLISS-16/36 ONLY 

If a call to a routine occurs in the scope of a global register data segment, 
then the register-number of the data segment must be given in either the 
GLOBAL or PRESERVE linkage-option of the called routine's linkage defi- 
nition. 

BLISS-32 ONLY 

If a call to a routine with CALL linkage-type occurs in the scope of a global 
register data segment, then the register-number of the data segment must 
be given in either the GLOBAL or PRESERVE linkage-option of the called 
routine's linkage definition. 

If a call to a routine with JSB linkage-type occurs in the scope of a global 
register data segment, then the register-number of the data segment must 
be given in either the GLOBAL or NOTUSED linkage-option of the called 
routine's linkage definition. 

10.8.3 Semantics 

A global-register-declaration causes a register data segment to be allocated. A 
global register data segment is a local data segment just like an ordinary 
register data segment — it is created on entry to the block in which it is 
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contained and released on exit from that block. However, unlike an ordinary 
register data segment, a global register data segment is available in called 
routines under certain conditions, described briefly below and more fully in 
Chapter 13, "Linkages". 

In order to pass a global register data segment to a called routine, the linkage- 
definition of the called routine must contain the name and register-number of 
the data segment in its GLOBAL linkage-option. There may be more global 
register data segments available at a call than are specified in the linkage for 
the call; however, every global register data segment specified in the linkage 
must be available at the call. Only those global register data segments speci- 
fied in the linkage are available in the called routine. 

1 0.9 External-Register-Declarations 

An EXTERNAL REGISTER declaration specifies that a global register data 
segment created in a calling routine is used in the routine containing the 
declaration. This declaration must be used in combination with linkage defi- 
nitions that include appropriate GLOBAL linkage-options. 

10.9.1 Syntax 



external-register- 
declaration 


EXTERNAL REGISTER register-item ,... ; 


register-item 


register-name 

( = register-number ) 
( nothing J 

C : register-attribute ... ) 
( nothing J 


register-name 


name 


register-number 


compile-time-constant-expression 


register-attribute 


/ allocation-unit \ <= 16/32 Only 
1 extension-attribute J <= 16/32 Only 
/ structure-attribute \ 
J field-attribute | 
1 initial-attribute 1 
V preset-attribute / 



10.9.2 Restrictions 

The register-number, if given, must be the same as that specified in the 
GLOBAL linkage-option of the containing routine's linkage definition. 
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A register data segment must not occupy more than a full word. 

An external-register-declaration must be contained within a routine declara- 
tion whose linkage definition specifies the named global-register-segment. 

Suppose the routine-body of a given routine, routine A, contains the declara- 
tion of another routine, routine B. If a name is declared EXTERNAL REGIS- 
TER in routine A and is not declared in routine B, then the name cannot be 
used in routine B. Such usage would be an "up-level" reference and is not 
permitted for register data segments. 

All or the attribute restrictions given in Section 10.1.2 also apply to EXTER- 
NAL-REGISTER declarations. 

A name declared in an external-register-declaration must be used only as the 
operand of a fetch expression or as the first operand of an assignment expres- 
sion. (This restriction does not apply to certain machine-specific-function 
parameters; see the applicable BLISS User's Guide.) 

10.9.3 Defaults 

If an external-register-declaration does not specify a register-number, the reg- 
ister-number given for that external-register-name in the GLOBAL linkage- 
option is assumed. 

10.9.4 Semantics 

An external-register-declaration specifies that a global register data segment 
created in a calling routine is available for use. The declared name must also 
be specified in the called routine's linkage definition; however, not all of the 
global register data segments specified in the linkage need be declared in an 
external-register-declaration. 

BLISS- 16/36 ONLY 

If a global-register-segment is specified in the routine's linkage but is not 
declared EXTERNAL REGISTER, then the contents of the register are 
preserved by the called routine and the register is available for other pur- 
poses. 

BLISS-32 ONLY 

If a global-register-segment is specified in the routine's linkage but is not 
declared EXTERNAL REGISTER, then in a routine with CALL linkage- 
type the contents of the register are preserved by the called routine and the 
register is available for other purposes. In a routine with JSB linkage-type, 
however, the contents of such a register cannot be preserved and the regis- 
ter is not usable in any way. 



10.10 Map-Declarations 



A map-declaration is used to supply new attributes in the current block to a 
name that is already declared. 
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The most common use of a map-declaration is in the declaration of the for- 
mal-names of a routine-declaration. Each formal-name is considered to be 
declared as a fullword, unsigned scalar data segment in an imaginary block 
that surrounds the routine-body. When those attributes are not suitable, a 
MAP declaration is used to override these defaults. This use of a map-declara- 
tion is discussed in Chapter 12, on "Routines". 

10.10.1 Syntax 



map-declaration 


MAP map-item ,... ; 


map-item 


map-name : map-attribute ... 


map-name 


name 


map-attribute 


/ allocation-unit \ <= 16/32 Only 
1 extension-attribute 1 <= 16/32 Only 
I structure-attribute > 
1 field-attribute 1 
V volatile-attribute / 



10.10.2 Restrictions 

A map-declaration must lie within the scope of another declaration of the 
same name. The latter declaration must be a data-declaration or a bind-data- 
declaration. 

BLISS-16/32 only: A structure-attribute must not appear in the same decla- 
ration as an allocation-unit or an extension-attribute. 

A field-attribute can appear only in a declaration that has a structure-attrib- 
ute. 



10.10.3 Semantics 

The declaration of a name as MAP changes neither the value of the name nor 
the contents of the data segment designated by the name. Instead, the storage 
whose address is given by the declared name is re-interpreted in accordance 
with the attributes given in the map-declaration. 
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Chapter 11 
Data Structures 



A data structure is the framework for a collection of values that are stored 
under a single name. Certain frequently -used data structures are predefined 
in BLISS; they are the vector, the bit vector, the block, and the blockvector. 
The use of these data structures is described in Chapter 3 on "Values and 
Data Representations". 

This chapter describes the features of BLISS that permit a programmer to go 
beyond the predefined data structures and design special data structures that 
fit a particular application. 

The first section of this chapter discusses the concepts of data structures and 
provides a detailed example of a specific data structure. 

The next section describes the field-reference, which is the fundamental 
BLISS mechanism for accessing an element of a data structure. 

The next seven sections describe the features of BLISS that are used to define 
and use a data structure; they are structure-declarations, structure -attrib- 
utes, field-declarations, field-attributes, ordinary-structure-references, de- 
fault-structure-references, and general-structure-references. 

The final two sections return to the description of specific data structures. 
One section gives the full definition of each of the BLISS predefined struc- 
tures. The remaining section gives several examples of programmer-defined 
structures. 

11.1 Introduction to Data Structures 

The BLISS facilities for programmer-defined data structures have the follow- 
ing benefits: 

1. Generality. If a specific application requires a data structure that is 
different from any predefined data structure, the programmer can de- 
fine a new data structure that fills the need. 
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2. Flexibility. If a specific application requires a different representation 
for an existing kind of data structure (for example, one that requires less 
space), the programmer can provide a new data structure that provides 
the required representation. 

3. Machine-Independence. If a program must depend on the architecture 
of the computer in order to save space or execution time, that depen- 
dence can be localized and concealed within the appropriate data struc- 
ture definition. 

4. Checking. If references must be checked for validity (for example, vec- 
tor subscript in range), an appropriate check can be built into a pro- 
grammer-defined structure definition. 

The design for a new data structure has three parts: the abstract definition, 
the concrete representation, and the programmed description. The abstract 
definition and concrete representation are part of the design of a program; 
although they may be written down as part of the documentation, they are not 
a part of the BLISS program. On the other hand, the programmed description 
of a data structure is part of the BLISS program in which the structure is 
used. 

This introductory discussion of data structures requires a specific example; 
therefore, a data structure called a "decimal digit array" is carried through 
each section of this discussion. The concrete representation and programmed 
description for the example structure is first worked out for the VAX-11 and 
BLISS-32. Further on, concrete representations and programmed descriptions 
are given for the PDP-11 and BLISS-16, and the DECSYSTEM-10/20 and 
BLISS-36. 

11.1.1 The Abstract Definition of Data Structures 

An abstract definition of a data structure specifies the structure, content, and 
usage of a particular collection of data in terms of its application, not in terms 
of a particular computer implementation. Indeed, the definition is abstract 
only if it applies equally to all possible representations of the data. 

The abstract definition of the decimal digit array might be: 

A decimal digit array is a compact storage representation of a sequence of 
decimal digits that permits reasonably quick access to individual digits. 

The decimal digit array is not a predefined structure in BLISS and it is not 
even an especially important structure. However, it is typical of the sort of 
data structure that can be readily defined by a BLISS programmer. 

The abstract definition of the decimal digit array establishes four characteris- 
tics of the desired structure: 

1. The word "compact" asserts that the representation cannot waste 
space, presumably because there will be many decimal digit arrays or 
because some of them will have many elements. 

2. The word "sequence", as well as the word "array" in the name of the 
structure, indicates that the elements of the structure are ordered. 
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The words "decimal digit" indicate that each element can have ten 
distinct values, and these values are associated with the characters "0", 
"1", and so on, through "9". 



4. The phrase "permits reasonably quick access to individual digits" pro- 
vides important information about the usage of the data structure. 

Observe the cautious wording of the third fact: it asserts that each element 
accommodates a range of ten values (which requires somewhat less than four 
bits), not that each element accommodates a decimal digit character code 
(which would require seven or eight bits in ASCII). 

11.1.2 The Concrete Representation of Data Structures 

The concrete representation of a data structure determines which bits of 
memory are occupied by the data and how these bits are interpreted. The 
design of the representation depends on the following considerations: 

1. The amount of storage available for the structure. If the structure is big, 
it should not contain a large proportion of unused storage. 

2. The amount of time available for access to the fields of the structure. If 
the structure is accessed frequently, each access should be fast. 

3. The effect of the representation on program development. If the ele- 
ments must be accessed during debugging, that access should be con- 
venient. 

4. Compatibility with other representations of the same data. If a commit- 
ment to a given representation has already been made, it may be neces- 
sary to accept that representation even if it is not optimal. 

The design of a concrete representation is difficult, especially at the beginning 
of a project. The facilities of BLISS permit a programmer to change concrete 
representations easily, even after the project is under way. 

The possible representations for a data structure can be ranked according to 
time and space requirements. The ranking can begin with those that have 
compact storage but slow access and proceed to those that have fast access 
but excessive storage. 

As an example, such a ranking for the decimal-digit-array data structure on 
the VAX- 11 target system would be: 

1. Since 32 bits can accommodate any nine-digit decimal number, the 
array can be stored nine digits per fullword. In this representation, 
however, access to a single digit requires considerable computation 
(conversion of a thirty-two-bit binary integer to a nine-digit decimal 
integer). 

2. Since 4 bits can accommodate ten distinct values, the array can be 
stored eight digits per fullword. This representation requires a conver- 
sion to get from the element value to an ASCII character but the con- 
version is a simple addition or OR operation. 
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4. 



Since the ASCII codes for decimal digits normally occupy eight bits 
each, and since the byte is a natural unit of storage on VAX-11, the 
array can be stored four digits per full word. In this representation, 
about half the storage is wasted, but access is quicker. 

Since VAX-11 works best on fullword values, the array could be stored 
one digit per fullword. This representation wastes a lot. of storage, but 
provides the most rapid access. 



Ranking representations in this way is useful, but sometimes difficult. Many 
considerations can affect the ranking, for example, both virtual and physical 
memory management strategies. The ranking might even be different for 
different models of the VAX-11. 

Each of these concrete representations is correct for certain situations. For the 
example under consideration, the representation in item 2 is chosen. That 
choice is interesting because it leads to a data structure that is not predefined 
in BLISS. 

The representation just chosen for a decimal digit array can be diagrammed 
for the VAX-11 as follows: 



DDA 



X[1],4 


X[0],4 




X[2],4 







:X 



This diagram differs from those given in Section 3.2. In Chapter 3, the intent 
was to represent data structures in a machine-independent way. Here, the 
intent is to represent the specific layout of the data structure in VAX-11 
storage. 

The diagram depicts a sequence of bytes in VAX-11 storage. The first line of 
the diagram (X[l] and X[0]) is the first byte allocated for the array. The 
second line (... and X[2]) is the second byte. The third line suggests successive 
bytes. 

The diagram represents a specific instance of a decimal digit array. The name 
of the array is X; that is, the value of X is the address of the first byte of the 
array. The name X is written to the right of the diagram because of the 
VAX-11 convention of indexing bits and bytes from right (low order) to left 
(high order). 

The diagram shows that the first element of the vector is called X[0] and 
contains 4 bits. That element occupies the four low-order bits of the byte 
whose address is X. The second element is called X[l] and occupies the four 
high-order bits of the byte whose address is X. The third element is called 
X[2] and occupies the four low-order bits of the byte whose address is X+l. 
The remaining elements of the structure are designated in a similar way. 
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The name DDA (for decimal digit array) at the top of the diagram refers to 
the layout of the fields relative to the starting address of the structure. There 
could be more than one DDA structure in storage at a given time, one at X 
and others at other addresses. 

11.1.3 The Programmed Description of Data Structures 

Once the abstract definition and concrete representation of a structure have 
been designed, the facilities of BLISS can be used to describe and use the 
structure. The principal facilities are structure-declarations, structure -attrib- 
utes, and structure-references. However, before these facilities can be de- 
scribed, field-references must be considered. 

11.1.3.1 Field-References — A field-reference is a BLISS construct that can 
designate any portion of storage that is %BPVAL bits or less in size. For 
example, a field-reference can designate a sequence of 15 bits starting with the 
second bit of the addressable unit whose address is 3116. 

A field-reference has the form: 

addr < pos, size, ext > 
where: 

addr is interpreted as an addressable-unit address. 

pos is the number of (least significant) bits skipped before the field 
begins. 

size is the number of bits in the field. 

ext is or 1 depending on whether unsigned or signed extension is used 
in fetching the contents of the field. 

The ext parameter can be omitted if unsigned extension is suitable. Sign 
extension is described in Section 3.1.3, and a full description of field-refer- 
ences is given in Section 11.2. 

Restrictions on the values of addr, pos, and size are different in each BLISS 
dialect because of differing capabilities of the respective target architectures. 
Briefly stated, field-references in BLISS-32 can designate any field of up to 
%BPVAL bits without regard to address boundaries; while field-references in 
BLISS-16 and BLISS-36 must designate fields that are completely contained 
within one fullword. 

The BLISS-32 field-references for the decimal digit array X (diagrammed in 
Section 11.1.2) are: 

<o»4> (first element, X[0]) 

<4»4>. (second element, X[l]) 

<B»4> (third element, X[2]) 
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The field-reference for the third element is typical; it is interpreted as follows: 

Find the addressable unit (VAX-11 byte) whose address is X. Start at the 
low-order bit of that unit of storage and skip forward across 8 bits. Use the 
next 4 bits as the field. 

In this definition, "skip forward" means proceed toward higher order bits and 
toward higher storage addresses. 

Field-references can handle any memory access required in BLISS. However, 
they are very dependent on the concrete representation of data structures. 
The features described in the following sections are designed to confine the 
use of field-references to a special place, the structure-declaration, and thus 
localize the dependence of a program on representation. 

11.1.3.2 Structure-Declarations — The following program fragment contains 
the structure-declaration for BLISS-32 decimal digit arrays (DDAs). 

STRUCTURE 

DDACi; N] = 

[ (N+l ) /2] 
DDA<4*I t Q> 5 

■% 
OWN 

X; DDAC103; 

♦ ♦ ♦ 

X [ 5 ] = , X [ 6 ] ; 

The first four lines of the example are the structure-declaration. Each line has 
a different purpose, as follows: 

1. "STRUCTURE" is the keyword for the declaration. 

2. "DDA[I; N] =" gives the structure-name, DDA, and the formal names I 
and N. The name I before the semicolon is an access-formal, and is used 
when an instance of the structure is referenced. The name N after the 
semicolon is an allocation-formal, and is used when an instance of the 
structure is allocated. 

3. "(N+l)/2" is the structure -size and determines the number of address- 
able units (bytes in this case) allocated for each instance of the struc- 
ture. 

4. "DDA<4*I,4>" is the structure-body and provides a field-reference for 
each reference to the structure in the program. (Note that, because of 
dialect-specific differences in field-reference limitations noted above, 
this particular structure-body definition is valid in the general case only 
in BLISS-32.) 

Observe that in the structure-size and structure-body a fetch operator, ".", is 
not used before a formal name to refer to the value of an actual parameter. In 
this sense structure formal names are like macro formal names (see Chapter 
16) and unlike routine formal names (see Chapter 12). 
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11.1.3.3 Structure Allocation — A structure-declaration does not allocate any 
particular instance of a data structure; it just associates a name with a de- 
scription of a structure. 

An instance of a given structure is allocated when its name is used in a 
structure-attribute in the declaration of a data segment name. The following 
declaration allocates a 10-element instance, named X, of a decimal digit 
array: 

OWN 

X: DDA CIO]? 

The compiler determines how much storage to allocate for X by making a 
copy of the structure-size, "(N+l)/2", replacing N, the allocation-formal, by 
10, and evaluating the expression. The result is 5 and thus five bytes are 
allocated. 

The example structure-size expression is also valid for BLISS-16 (assuming 
an identical concrete representation for DDA), since the addressable-unit size 
is the same. The structure-size expression required for BLISS-36, assuming a 
similar concrete representation for DDA, is given in Section 11.1.3.7. 

11.1.3.4 Structure-References — The following assignment contains two ex- 
amples of references to the decimal digit array named X: 

X C 5 ] = ♦ X C G ] ; 

When the program is compiled, the first structure-reference is replaced by a 
copy of the structure-body from the declaration of DDA. Then, within the 
structure -body, DDA is replaced by X and I is replaced by 5. The second 
structure-reference is compiled in the same way, except that I is replaced by 
6. The result is: 

X<4*5»4> = .X<4*6»4>5 

The actual-parameter of a structure -reference need not be a numeric-literal as 
in this example; it can be any expression. For example, the assignment 

XC.J3 3 = .XC.J3+1]? 

is expanded by the compiler into: 

x< 4* ( . J3 ) >a > = . x< a* ( ♦ J3+ 1 ) , a > 5 

In this case, the fields selected depend on the contents of J3 each time the 
assignment is executed. 

Similar examples of the structure-body expression for BLISS-16 and 
BLISS-36, assuming an identical or similar concrete representation for DDA, 
are given in Section 11.1.3.7. 

11 .1 .3.5 REF Structures — It is sometimes useful to manipulate the addresses 
of data structures. It is easy to manipulate addresses in BLISS, but the 
compiler needs information about the structures to which the addresses refer. 
This information is supplied with the help of the REF keyword and an appro- 
priate structure -attribute in the declaration of storage for a structure address. 
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As an example of the use of REF, consider the following program fragment: 



STRUCTURE 




DDAC I 5 N] = 




C (N+l )/2] 




DDA<4*I tU> 5 


♦ ♦ ♦ 

OWN 






X: DDAC 10] f 




Y: DDAC 10] 5 


OWN 






ALPHA t 




PDDA: REF DDAC 10] 5 



IF .ALPHA EOL THEN PDDA=X ELSE PDDA=Y5 
PDDAC5] = .PDDACBD5 

The interpretation of the final assignment depends on the value of PDDA and 
the value of PDDA is determined, at run time, by the contents of ALPHA. If 
ALPHA contains zero, the assignment is equivalent to: 

X C 5 ] = . X c s ] ; 
Otherwise it is equivalent to: 

Y C 5 ] = . Y C G ] 5 

A name that is declared with REF designates a data segment that contains 
the address of a structure. Since an address always occupies a fullword, a 
full word is always allocated for such a name. In the example above, PDDA is 
the address of a fullword that contains either the address X or the address Y. 

When a name that is declared REF is used in a structure-reference (and is 
therefore followed by a list of parameters in brackets), an extra level of in- 
direction is automatically supplied. Thus in the assignment 

PDDAC5] = .PDDACG]; 

the address of the structure to which a value is assigned is not PDDA but is 
rather the contents of PDDA. Similarly, the address of the structure from 
which a value is fetched is not PDDA but is rather the contents of PDDA. 

When a name that is declared REF is not used in a structure reference, it is 
interpreted without the extra level of indirection. (If this were not the case, 
then the contents of a data segment used as a pointer to a structure could not 
be changed.) Thus in the assignment: 

PDDA = x; 
the address of the data segment to which a value is assigned is PDDA. 

11.1.3.6 Interchangeable Structure-Declarations — It is quite natural to use 
different structure-declarations for the same abstract structure at different 
stages in the development of a program. Three possible declarations for deci- 
mal digit arrays are: 

• The declaration already considered in the preceding sections is: 

STRUCTURE 

DDACi; N] = 

C (N+l )/2] 
DDA<4*I »4>i 
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This declaration was presented as the one that implements the chosen 
concrete representation for decimal digit arrays. 

• A second declaration of DDA is: 

STRUCTURE 

DDACI5 N] = 
EN] 
DDA<8*I »B> ! 

This declaration provides for faster access to the elements but uses twice 
as much storage. 

• A third declaration of DDA is: 

STRUCTURE 

DDACi; N] = 
CN3 
BEGIN 

IF I LSS OR I GTR N-l THEN ERROR ( DDA , 1)5 
DDA 
END<8*I t8>? 

This declaration is oriented toward debugging. Specifically, 

1. It uses a full byte (instead of 4 bits) for each element of the array. 
Thus the examination of memory is easier. 

2. It includes a check on the value of the subscript I to make sure that it 
is in the range from to N-l. Thus this class of errors is detected 
automatically. 

Thus this declaration can be used during the development of a program 
and one of the previous declarations of DDA can be used for the produc- 
tion version of the same program. 

The debugging declaration just given illustrates an interesting feature of 
structures. Suppose the following program fragment lies within the scope of 
the debugging declaration: 

OWN 

)•(: DDA CIO] t 

Y: DDA C 20]5 
» ♦ » 

X C . J ] = . Y [ . K ] ; 

The compiler expands the assignment on the last line into the following as- 
signment: 

BEGIN 

IF .J LSS OR »J GTR 9 THEN ERROR ( DDA » .J) 5 

DDA 

END<8*» J »8> 

BEGIN 

IF ,K LSS OR ,K GTR 19 THEN ERR0R(DDA> ,K>; 

DDA 

END<8*.K ,8>» 

This example shows that the compiler saves the value of the allocation-pa- 
rameter, N, each time the structure is allocated. For X this value is 10, for Y it 
is 20. Thus this value can be used in the structure-body and, eventually, in 
each structure-reference. 
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11.1.3.7 Decimal Digit Arrays in BLISS-1 6 and BLISS-36 — For a packed 4- 
bits-per-digit representation of a decimal digit array in BLISS-36, a different 
structure-size definition is required for the following reasons: 

• The smallest (and only) addressable unit in BLISS-36 is the fullword, 
rather that the byte as in BLISS-16 and BLISS-32. 

• The 36-bit fullword of BLISS-36 can nicely accomodate nine 4-bit digits. 

Instead of the BLISS-16/32 structure-size expression "(N+l)/2", which allo- 
cates one 8-bit addressable unit for each two elements required plus one unit 
for an odd final element, the following expression is appropriate for 
BLISS-36: 

<N+8)/9 

This structure-size expression allocates one 36-bit word for each nine ele- 
ments required plus one word for a final (or only) group of less than nine. 

As noted above, the BLISS-32 structure-size expression is also valid for 
BLISS-16, since the respective target systems have the same basic storage 
allocation unit (i.e., the byte). 

The structure-body definition given for DDA in BLISS-32 needs to be modi- 
fied in both BLISS-16 and BLISS-36 because neither of these dialects allows 
the position value of a field-reference to exceed %BPVAL (as it can in 
BLISS-32). In BLISS-16 the DDA structure-body can be defined as: 

(DDA+I/2X(I MOD 2)*4>4> 

Alternatives to this expression, which are logically equivalent but better in 
terms of object-code efficiency, are the following: 

(DDA+I/2XIF I THEN 4 ELSE 0>4> 

or 

(DDA+I/2X ( I AND 1)*4>4> 

or 

(DDA+I/2) < (1-2) AND 4 ,U> 

These alternatives are listed in order of increasing space efficiency, although 
the first alternative results in the fastest code sequence. 

In BLISS-36 the DDA structure-body can be defined as: 

<DDA+I/9X(I MOD 9>*4>4> 

To summarize, the BLISS-16 and BLISS-36 forms of the DDA structure- 
declaration are the following: 

• For BLISS-16— 

STRUCTURE 

DDACi; N] = 

C (N+l )/23 

(DDA+I/2X (1-2) AND 4 »4>5 
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• For BLISS-36— 

STRUCTURE 

DDACI! N] = 

C (N+8>/9] 

(DDA+I/9X ( I MOD 9>*4 »4> 

The user's guide for each BLISS dialect describes, under "Transportability 
Guidelines", the development of generalized, fully transportable structure- 
declarations. In particular, it describes a general packed- vector data structure 
called GEN VECTOR which produces the same concrete representation de- 
scribed here as DDA on any target system. 

11.1.4 Conclusion 

All high level languages provide the programmer with a set of predefined data 
structures. Some programming languages provide facilities for the definition 
of new abstract data structures based on predefined data structures. BLISS 
goes beyond such facilities and provides for the definition of new concrete 
data structures. 

Thus, when the need arises, a BLISS programmer can access storage just as 
freely as an assembly language programmer can. The programmer can desig- 
nate any addresses, any fields, any bits in storage. 

The structure-declaration is the interface between the implementation of a 
given data structure and its use in the program. On one side of the interface 
lies the specific layout of the structure, with machine-specific details and an 
appropriate concern for efficiency. On the other side of the interface are the 
many references to the structure, each treating it as an abstract, machine- 
independent entity. For each data structure, communication between the two 
sides is by a single name, such as DDA used for the example in this section. 

Because the predefined structures of BLISS use the same facilities of BLISS 
as programmer-defined structures, they provide a point of departure for data 
description rather than presenting a restrictive barrier. 

The BLISS facilities for data structures are unusual and relatively compli- 
cated. They depend on the combination of the various declarations, attrib- 
utes, and references described in this chapter. The concluding sections of this 
chapter, Section 11.10 on predeclared structures and Section 11.11 on typical 
programmer defined structures, show how these facilities are combined to 
define and use specific structures. 
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A field-reference designates a sequence of up to %BPVAL bits of storage. It is 
normally used as the operand of a fetch operator or the left operand of an 
assignment operator. With certain restrictions, however, a field-reference can 
be used in any context that requires an address value. 
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Structure-declarations use field-references to map abstract, machine-inde- 
pendent structures into concrete, machine-specific storage units. Thus, when 
suitably parameterized, they support the writing of programs that are effi- 
cient and yet transportable from one target system to another. 

Field-references should be used only in structure-declarations. The use of 
field-references in any other context introduces machine-dependence in a 
confusing and disorganized way. 

Examples of field-references are given in Section 11.1.3.1. 
11.2.1 Syntax 



field-reference 


address (^Id-selector j 
( nothing J 


address 


( primary ) 
\ executable-function J 


field-selector 


< position , size ( ' sign-extension-flag j > 
( nothing ) 


position ) 
size J 


expression 


sign-extension-flag 


compile-time-constant-expression 



In addition to the syntactic rules just given, the following syntactic rules are 
required: 

1. A field-selector that could be part of several fetch expressions is, in fact, 
part of the innermost of them. 

2. A field-selector that could be part of either an assignment expression or 
a fetch expression is part of the fetch expression. 

An example of an expression to which Rule 1 applies is: 

. ,BETA<8 t8> 

This expression is interpreted as: 

. ( .BETA<8 »B>) 

rather than as: 

. ( .BETA KB »8> 

In this example, the given expression is composed of one fetch expression 
within another, and Rule 1 is needed because one of the fetch expressions does 
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not have a field -selector. In the first interpretation, the field-selector is part of 
the inner fetch expression, and is, therefore, applied to the data segment 
whose address is BETA. In the second (nondefault) interpretation, the field- 
selector is part of the outer fetch expression and, therefore, is applied to the 
data segment whose address is .BETA. 

An example of an expression to which Rule 2 applies is: 

♦Q<0>8> = .A+i 

This expression is interpreted as: 

( .Q<0 >8>) = ♦ A+l 

rather than as: 

( .0X0 >8> = .A+l 

In the first interpretation, the field-selector is part of the fetch expression and 
the assignment is made, by default, to a fullword. In the second (nondefault) 
interpretation, the field-selector is part of the assignment expression, and the 
fetch is made, by default, from a fullword. 

11.2.2 Restrictions 

The restrictions on the address, position, and size expression values in a field- 
selector are different for each BLISS dialect, as follows: 

BLISS-16 ONLY 

The size of a field may range from to 16 bits, inclusive, but a field must 
not cross a machine-word boundary. This implies two sets of specific re- 
strictions on the position (p) and size (s) values, as follows: 

(a) If the field-selector is applied to a even-numbered byte (i.e., word- 
aligned) address, then 

< p 

< s < 16 

< p+s < 16 

(b)If the field-selector is applied to an odd-numbered byte address, then 

< p 
< s < 8 
< p+s < 8 

BLISS-32 ONLY 

The value of the size expression may range from to 32, inclusive, and the 
field so specified may cross a longword boundary. More specifically, there is 
no restriction on the position expression relative to storage-address bounda- 
ries, and the restriction on size (s) is 

< s < 32 



Data Structures 11-13 



BLISS-36 ONLY 

The value of the size expression may range from to 36, inclusive, but the 
field so specified may not cross a machine-word boundary. More specifi- 
cally, the restrictions on position (p) and size (s) are 

< p 

< s < 36 

< p+s < 36 

The value of the sign-extension-flag must be or 1. 

A field-selector must not be immediately followed by another field-selector. 
For example, 

♦Z<0»16><8»2> = .BETA 

is not valid. (Parentheses can be used to avoid this restriction. For example, 

<.Z<0>1B>)<8»2> = .BETA 

is a valid expression.) 

Normally a field-reference is the operand of a fetch operator or the left oper- 
and of an assignment operator. When a field-reference is used in any other 
way, it must specify a field that begins on an addressable-unit boundary; that 
is: 

• The value of the position expression must be or 8 in BLISS-16, must be 
or a multiple of 8 in BLISS-32, and must be in BLISS-36. 

• The address expression must not be a register-name. 

• The position and size expressions must be compile-time-constant-expres- 
sions. 

When the address in a field-reference is a register-name, the field-reference 
must specify a field that lies entirely within the designated register; that is, 
the position expression must be greater than or equal to and the sum of the 
position and size expressions must be less than or equal to %BPVAL. 

11.2.3 Default 

The default value for the sign- extension- flag is 0. 

11.2.4 Semantics 

A field -reference specifies a field of up to a fullword (%BPVAL bits) in size 
relative to a given storage address. Certain aspects of the field-selector seman- 
tics are dialect dependent, as described in the following three paragraphs. 

In BLISS-16, the field is specified relative to a byte address, and the field 
must be completely contained in the machine word containing the given byte. 

In BLISS-32, the field is specified relative to a byte address, and the field 
may occur anywhere in storage relative to the given byte. 

In BLISS-36, the field is specified relative to a word address, and the field 
must be completely contained in the given machine word. 
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Depending on the context in which it appears, a field-reference has one of the 
interpretation given below. (These rules do not apply to field-references in the 
structure-body of a structure-declaration, because the structure-body is not 
interpreted as part of the declaration of a structure; rather, these rules apply 
when the structure-body is used in the interpretation of a structure-reference, 
as described in Sections 11.7, 11.8, and 11.9.) 

• Fetch Context. If the field-reference is the operand of a fetch expression 
(defined in Section 5.1), having the form: 

. e2 field-selector 

then evaluate the fetch expression as follows: 

1. Interpret the address expression, e2, as follows: 

a. If the address is a register-name, then call the register the selected 
unit. 

b. Otherwise, let a be the value of the address expression. Locate the 
addressable-unit in storage whose address is a. Call this address- 
able-unit the selected unit. 

2. Let p be the value of the position expression. Locate the sequence of p 
bits that starts with the low-order bit of the selected unit. Call these 
bits the offset field. 

3. Let s be the value of the size expression. Locate the sequence of s bits 
that immediately follows the offset field. Call these bits the selected 
field. 

4. Obtain a full word value as follows: 

a. If s = %BPVAL, fetch the contents of the selected field. 

b. If < s < %BPVAL, fetch the contents of the selected field and 
extend it to a full word as follows: 

1) If the value of the sign-extension-flag is 0, then extend the 
selected field by adding zero-bits at the left. 

2) Otherwise, extend the selected field by adding copies of the sign 
bit (leftmost bit) of the selected field at the left. 

c. If s = 0, use the full word representation of zero. 

5. Use the value just obtained as the value of the fetch expression. 

• Assignment Context. If the field-reference is the left operand of an as- 
signment expression (defined in Section 5.1), having the form: 

el field-selector = e2 

then evaluate the assignment expression as follows: 

1. Locate the selected field of storage, relative to el, as in Steps 1 
through 3 for the fetch context. 
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2. Let s be the value of the size expression and let v2 be the value of the 
right operand, e2, of the assignment expression. Store a value as 
follows: 

a. If s = %BPVAL, store v2 in the selected field. 

b. If < s < %BPVAL, store the rightmost s bits of v2 in the se- 
lected field. 

c. If s = 0, do not store a value. 

3. Use the full word value of e2 as the value of the assignment expression. 

• Other Contexts. If a field-reference appears in some other context, then 
evaluate the field -reference as follows: 

1. Let a be the value of the address expression and let p be the value of 
the position. Compute 

a + p/%BPUNIT 

Observe that a restriction in Section 11.2.2 requires that the address 
must not be a register-name, and the value of p must be zero or, in the 
case of BLISS-16/32, a multiple of 8, so that the value of p/%BPUNIT 
is an integer. Also observe that the values of the size and sign-exten- 
sion-flag expressions are not used, but the restrictions on these values 
still apply. 

2. Use the value just computed as the value of the field-reference. 
The following considerations apply to the interpretation of field-references: 

• The order in which the address, position, size, and sign-extension-flag 
expressions are evaluated is not defined (see Section 5.1.4). 

• The sign-extension-flag is ignored in all contexts except a fetch expres- 
sion. 

• The description of the field-reference just given uses phrases like "se- 
quence of p bits that starts with..." and "sequence s of bits that immedi- 
ately follows...". Thus it assumes an ordering of bits in storage. That 
ordering, based on numeric significance, is: 

For BLISS-16 and BLISS-32 

Bit The low-order bit of byte n 



Bit 7 The high-order bit of byte n 

Bit 8 The low-order bit of byte n+1 



Bit 15 The high-order bit of byte n+1 
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BLISS-32 ONLY 

Bit 16 The low-order bit of byte n+2 



Bit 23 The high-order bit of byte n+2 
Bit 24 The low-order bit of byte n+3 



For BLISS-36 

Bit The low-order bit of word n 



Bit 35 The high-order bit of word n 

• Observe that in BLISS-32, although the selected field cannot be longer 
than 32 bits, it can occur anywhere in storage, crossing boundaries be- 
tween bytes, words, or longwords. 

11.2.5 Discussion 

The BLISS bit numbering convention, defined above, is consistent across the 
BLISS dialects: bit-position is always the "rightmost" or least significant 
bit of the specified addressable unit, for all target systems. 

Several aspects of field-references are discussed in the following subsections. 
First, some examples are given to illustrate various cases. Second, the place- 
ment of a field-selector in the definition of a structure is discussed. And third, 
the general and fundamental relationship of field-references to expressions is 
discussed. 

11.2.5.1 Examples — Field-references used in fetch and assignment contexts 
are illustrated throughout this chapter and do not require further elaboration 
here. However, field-references used in other contexts involve some special 
considerations. 

As stated in Section 11.2.4, a field-reference that is not in a fetch or assign- 
ment context computes a value according to the formula 

b + p/%BPUNIT 

In BLISS-32 and to a limited extent in BLISS-16, such field-references allow 
the programmer to compute the address at which a field begins. Such address 
values might be assigned to another data segment for later use or passed as 
actual-parameters of a routine-call. Observe that the restrictions in such cases 
(the byte-address is not a register name, position and size are compile-time 
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constant values, and the position is zero or a multiple of 8) assure that the 
compiler can verify that the field does begin at a byte address and hence, that 
the above formula can be computed. 

Consider the following examples: 

Example Comment 

A = x The address of the data segment X is assigned to A. 

A = x< o > 8 > The address of the data segment X is assigned to A (as in 

the previous example). 

a = x<io»iz> Invalid. The field-reference does not designate a field 
that begins at a byte address. 

A = x<8,8> Invalid in BLISS-36; valid in BLISS- 16/32. The address 

of the data segment X plus 1 is assigned to A. This field- 
reference is equivalent to the field-reference (X+l)<0,8>. 



i » 



i > Invalid. The position expression is not a compile-time 
constant value and, therefore, the field might not begin at 
a byte address. 

Observe that in BLISS-16 the effective range of p/8 is simply or 1; in 
BLISS-32 the range of p/8 is unrestricted; and in BLISS-36 the range of p/36 
is (only) 0. Consequently, the value of a field-reference in BLISS-36 is effec- 
tively the same as the address part of the field-reference and the term 
"p/%BPUNIT" in the formula for the value has no practical utility. 

11.2.5.2 Field-References in Structure-Declarations — The definition of a 
structure-name can include a field-reference as the structure-body (see Sec- 
tion 11.3), but when the structure-body involves a block, a common error is to 
place the field-selector inside the block instead of following the block. 

An example of correct placement of the field-selector following the block was 
given in Section 11.1.3.6; it is repeated here: 

STRUCTURE 

DDAEIiN] = 
EN] 
BEGIN 

IF I LSS OR I GTR N-l THEN ERROR (DDA» I ) *i 
DDA 
END<8*I ,8>! 

Suppose the last two lines of this example are coded as follows: 

♦ ♦ ♦ 

DDA<8*I >8> 

end; 

This coding has a quite different meaning than the one intended. Because the 
field-reference is contained inside the block, the rule for a field-reference in a 
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context other than a fetch or assignment context always applies. When the 
structure-reference is used in a fetch or assignment, a fullword fetch or assign- 
ment results according to the rules in Section 5.1 (assuming that the restric- 
tions on field-references do not result in an error). 

As can be seen in this example, the placement of the field-selector following 
the block is essential for the desired meaning. 

11.2.5.3 Field-References and Expressions in General — Consider again the 
first two examples in Section 11.2.5.1. They are: 

A = X 

A = X<0»8> 

In both cases, the address of the data segment X is assigned to A. These 
examples are especially interesting because they hint at a BLISS language 
design principle that ties together field-references and expressions in a very 
general way. 

The BLISS rules regarding expressions and data segments given elsewhere in 
this manual can be restated (in part) in the following way: 

1. The declaration of a data segment name associates an implicit, default 
field-selector with the name, which is determined as follows: 

a. If the data segment is a scalar, then the default field-selector is <0, 
size, sign> ./here: 

i. The size v£ le is, in BLISS-16 and BLISS-32, a multiple of 
%BPUNIT determined by the explicit or default allocation-unit, 
and in BLISS-36 is simply %BPUNIT, that is, 36. 

ii. The sign value is, in BLISS-16 and BLISS-32, or 1 according to 
the explicit or default extension-attribute, and in BLISS-36 is 
always 0. 

b. If the data segment is structured, then the default field-selector is 
<0, %BPVAL, 0>. (This default applies only when the data segment 
name does not appear in a structure-reference.) 

2. For any expression other than a data segment name, the default field- 
selector is <0, %BPVAL, 0>. (This default applies only when the ex- 
pression does not appear as the address-expression of a default-struc- 
ture-reference.) 

According to these rules, every expression in a BLISS program can be thought 
of as having a default field-selector. 

When the semantics for field-references given in Section 11.2.4 is applied to 
expressions with default field-selectors as described here, the resulting inter- 
pretation is equivalent to the semantics given in Chapter 5. The description 
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given there is used because it is simpler and more intuitive for the common 
cases. The description given here presents an important part of the conceptual 
foundation of BLISS. 

11.2.5.4 Operations on Scalar Field Values — When all values involved in a 
calculation occupy fullwords, the programming involved is relatively straight- 
forward. Fullwords accomodate maximum-size BLISS values and assignment 
from one fullword to another never modifies a value. 

When a scalar field value — a value smaller than a fullword and not part of a 
data structure — is involved in a calculation, however, problems can arise. 
They can arise either through assignment of a large value to the small field, or 
through incorrect extension of the contents of the field. An example of the 
former type of problem is the inadvertent assignment of a fullword value to a 
field that is not large enough to accomodate the significant portion of the 
fullword. Obviously some significance will be lost in the stored result. 

The latter type of problem can be more subtle; for example: 

OWN 



x < o > 8 > = - 1 ; 

Y = . X < » 8 > + 1 5 

♦ 4 I 

For purposes of discussion, assume that there is some good reason for using an 
8-bit field relative to address X (which cannot be determined from inspection 
of the program fragment). Since this field occupies less than a fullword, when 
fetched it is extended before being incremented and assigned to Y. And since 
the extension for the field is unsigned by default, the extended field value 
becomes 255 rather than -1. Thus the value of Y becomes 256 rather than 0, 
presumably not the intended result. 

The program fragment does not violate any rules of BLISS; it is valid. How- 
ever, since it assigns a negative number, -1, to a field that is by implication 
unsigned, the program fragment is at least ambiguous in its intent, if not 
incorrect. 

Depending on whether the result obtained was or was not the one intended, 
the program fragment can be altered in one of the following ways: 

• Change the numeric-literal from -1 to 255. This change does not affect 
the value assigned to Y, but does make clear that the result is the ex- 
pected one. 

• Replace the field-selectors shown with <0,8,1>, indicating signed value 
extension. This change causes to be assigned to Y. 

In BLISS-16 or BLISS-32, the problems just described can also arise through 
the use of an allocation-unit that causes field allocation of a scalar data 
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segment; that is, through the use of BYTE in BLISS-16, or BYTE or WORD 
in BLISS-32, as an attribute in a data declaration. This is due to the implicit 
relationship between allocation-units and field-selectors. An equivalent pro- 
gram fragment that uses the BYTE allocation-unit rather than explicit field- 
references to produce results identical to those described above is given in 
Section 5.1.5.3. 



11.3 Structure-Declarations 



A structure-declaration describes the organization of a data structure. It spec- 
ifies (or implies) a field-reference for every possible reference to the structure 
and thus defines the layout of the structure in storage. It also specifies an 
expression to be used to determine the amount of storage to be allocated when 
a structure is associated with a name in a data-declaration. 

An example of a structure-declaration in each of the BLISS dialects is: 

• In BLISS-16 — 

STRUCTURE 

UECTORCI! Nt UNIT=2, EXT=03 = 
CN*UNIT] 
<VECTOR+I*UNIT><0 ,8*UNIT »EXT>? 

• In BLISS-32 — 

STRUCTURE 

VECTORCIi N, UNIT=4, EXT=0] = 
EN*UNIT] 
(VECTOR + I*UNITK0»8*UNIT»EXT>i 

• In BLISS-36 — 

STRUCTURE 

UECTORCi; N] = 
CNH 
(VECTOR* I )<0 ,36>> 

These are equivalent declarations of the BLISS predeclared structure named 
VECTOR, but they do not differ in any significant way from structure decla- 
rations written by the programmer. 

The access-formal in this declaration is I and the allocation-formals are N 
and, in BLISS-16/32, UNIT and EXT. UNIT and EXT have default values of 
%UPVAL and 0, respectively. If in BLISS-16 or BLISS-32 a VECTOR struc- 
ture-attribute does not specify allocation-actuals for UNIT and EXT, then 
these default values are used. The structure-size expression is N*UNIT and 
the structure-body is (VECTOR + I*UNIT)<0,%BPUNIT*UNIT,EXT>. 

Observe that in the BLISS-36 VECTOR declaration, the allocation-formals 
UNIT and EXT are not included. This is so because BLISS-36 does not have 
the corresponding allocation-unit and extension-attribute (used in data-decla- 
rations in the other two dialects), and therefore these formal parameters are of 



Data Structures 11-21 



no practical use. If, however, these formal parameters were expressed in the 
BLISS-36 declaration and given their default values of %UPVAL (1 in 
BLISS-36) and (unsigned-extension), respectively, the BLISS-36 declara- 
tion would be not only explicitly equivalent — varying only in the dialect- 
specific values of %UPVAL and %BPUNIT — but also operationally valid. 

11.3.1 Syntax 



structure-declaration 


STRUCTURE structure-definition ,... ; 


structure-definition 


structure-name 

r ( access-formal ,... ) 
( nothing ) 

( ; allocation-formal ,... ) 
( nothing } J 

_ i [ structure-size 3 ) 
( nothing ) 

structure-body 


allocation -formal 


allocation-name ( = allocation-default ) 
( nothing ) 


structure-size ) 
structure-body J 


expression 


structure-name \ 
access-formal I 
allocation-name J 


name 


allocation-default 


compile-time-constant-expression 



11.3.2 Restrictions 

A primary of a structure-size expression must be either an allocation-name or 
a compile-time-constant-expression. When a compile-time-constant-expres- 
sion is substituted for each allocation-name in the expression, the resulting 
expression must be a compile-time-constant-expression. 
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If the structure-body expression contains a block, only the following declara- 
tions can appear in the block: 

LOCAL EXTERNAL LITERAL 

STACKLOCAL EXTERNAL ROUTINE 

REGISTER LITERAL 
EXTERNAL 

11.3.3 Semantics 

The structure-size expression of a structure-declaration is utilized by the com- 
piler when the structure name appears in a structure-attribute of a data- 
declaration. It specifies the number of addressable units to allocate for the 
declared data segment. 

The structure-body is utilized each time a structure-reference appears in an 
expression. It specifies a replacement for the structure-reference that consists 
of an expression. Observe that a field-reference is one form of expression. 

The use of these portions of the structure-definition is described in the follow- 
ing sections on structure-attributes and storage allocation (Section 11.4) and 
structure-references (Sections 11.7, 11.8, and 11.9). 

11.4 Structure-Attributes and Storage Allocation 

The form of a data segment is determined when its name is declared. If a 
structure-attribute appears in the declaration, then that structure-attribute 
determines the structure of the data segment both for purposes of storage 
allocation and access. If no structure-attribute appears, then the data seg- 
ment is assumed to be a scalar. 

A structure-attribute in the declaration of a name provides two kinds of infor- 
mation. First, it provides a structure-name and thus associates a structure- 
definition with the name of the data segment. Second, it provides the alloca- 
tion-actual parameters for the structure-definition, and thus specifies the 
number of addressable units of storage to be allocated for the data segment. 

Observe that the parameters in a structure-attribute are positional; that is, 
the formal names given in the structure-declaration are not used as keywords 
in a structure-attribute. 

The complete syntax and semantics of the declarations in which a structure- 
attribute can appear are given in the chapters on data declarations (Chapter 
10) and on binding (Chapter 14). This section describes only the structure- 
attribute itself and how it is used to determine the size of a structured data 
segment. 
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11.4.1 Syntax 



structure-attribute 


i &&r 1 s tructure-name 
( nothing J 

( [ allocation-actual ,... ] ) 
\ nothing ) 


structure-name 


name 


allocation-actual 


/ compile-time-constant-expression \ 
1 allocation-unit 1 <= 16/32 
| extension-attribute | <= 16/32 
v nothing / 


16/32 Only 
allocation-unit 


( LONG )<= 32 Only 
\ WORD > 
( BYTE ) 


16/32 Only 
extension-attribute 


( SIGNED ) 
( UNSIGNED ) 



11.4.2 Restrictions 

BLISS-16/32 ONLY 

An allocation-unit used directly as an attribute cannot appear in the same 
declaration as a structure-attribute. Similarly, an extension-attribute used 
directly as an attribute cannot appear in the same declaration as a struc- 
ture-attribute. 

Unless the structure-attribute begins with REF or is in an EXTERNAL, 
MAP, or BIND declaration: 

1. A structure-size expression must appear in the definition of the struc- 
ture-name, and 

2. A non-null allocation-actual parameter must be given for each alloca- 
tion-name that appears in the structure-size expression and does not 
have an allocation-default. 

A non-null allocation-actual parameter must be given for each allocation- 
name that appears in the structure-body and does not have an allocation- 
default. 
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11.4.3 Semantics 

The allocation of a structure is performed by the compiler as follows: 

1. If in BLISS-16 or BLISS-32 an allocation-unit or extension-attribute 
keyword appears as an allocation-actual, it is replaced by a constant 
value as follows: • 

Keyword Replaced by 

LONG 4 <= 32 Only 

WORD 2 

BYTE 1 

SIGNED 1 

UNSIGNED 

2. The allocation-actual parameters are evaluated and the values are asso- 
ciated with the corresponding allocation-names in the specified struc- 
ture-definition. 

3. Any allocation-name that does not have a value already associated with 
it from Step 2, but does have an allocation-default value, is associated 
with its default value. 

4. The amount of storage to allocate for the declared name is determined 
as follows: 

a. If the structure-attribute appears in an EXTERNAL, MAP, or 
BIND declaration, then no storage is allocated. 

b. If the structure-attribute begins with the keyword REF, then one 
full word of storage is allocated. 

c. Otherwise, the structure-size expression is evaluated using the val- 
ues that are associated with each of the allocation-formal names. 
The resulting value specifies the number of addressable units of 
storage that are allocated. 

5. The structure-name and the values associated with each allocation- 
name are recorded with the data-segment name being declared, for use 
when the data-segment is referenced. 



11.5 Field-Declarations 



The FIELD declaration is used to define names of fields in BLOCK and 
BLOCKVECTOR predeclared structures, and in programmer-defined struc- 
tures that, are similar to BLOCK. 
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A BLISS-36 example of a field-declaration is: 



FIELD 










DCB 


-FIELDS 

SET 










DCB_A 


= 


CO 


»0 »3G »0] t 




DCB_B 


= 


c i 


1 t G 1 ] t . 




DCB_C 


= 


C 1 


t G » 1 2 » 3 » 




DCB_D 


= 


[ 1 


» 1 8 » 1 8 1 ] t 




DCB_E 


= 


[2 


»0 »3G »03 




TES5 









The field-names declared here are DCB A., DCB B, and so on. Each name 

can be used as a parameter in a structure-reference to represent a sequence of 

four access-actuals. For example, DCB A can be used to represent 

"0,0,36,0". (In other examples, the field-names might represent more or less 
than four access-actuals.) 

The example field-declaration just given also provides a field-set-name, 

DCB FIELDS. That name is used to refer to the field-names collectively as 

when, for example, they must be mentioned in a field-attribute. 

The field-declaration is a special-purpose facility that can best be explained 
in the context of a complete example of structure declaration and use. Such 
an example is given in section 11.10.3. 

11.5.1 Syntax 



field-declaration 


FIELD i field-set-definition ) 
, ( field-definition ) 


field-set-definition 


field-set-name = 
SET 

field-definition ,... 
TES 


field-definition 


field-name = [ field-component ,... ] 


field-set-name ) 
field-name ) 


name 


field-component 


compile-time-constant-expression 



11.5.2 Restrictions 

A field-name can only be used as an access-actual parameter of a structure- 
reference, a parameter of a field-attribute, or in the %FIELDEXPAND lexi- 
cal-function. 

A field-set-name can only be used as a parameter of a field-attribute. 
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11.5.3 Semantics 

The field-declaration defines names for use as access-actual parameters of 
structure-references to designate fixed fields in fixed data structures. As a 
notational convenience, a set of such field-names can be declared and referred 
to by a single name. Observe that both field-names and field-set-names follow 
the normal rules concerning scope and uniqueness of names; there is no con- 
cept like the "qualified names" of COBOL or PL/I. 

When a field-name appears as an access-actual parameter of a structure- 
reference, it is replaced by the list of field-component values from the field- 
definition. (See example in Section 11.10.3.5.) These values provide one or 
more of the access-actual parameters used in the evaluation of the structure- 
reference. A field-name need not itself supply all of the actual parameters 
required for the reference. (While this replacement has some of the character- 
istics of a macro expansion, field-names are not macro-names; in particular, a 
field-name is not valid in contexts other than a structure-reference.) 

The field-attribute specifies the set of field-names that can appear in ordi- 
nary-structure-references for the indicated data segment. If no field-attribute 
is given, then no field-name is valid. 

Any field-name can be used in a general-structure-reference. 



11.6 Field-Attributes 



A field-attribute is used in the declaration of a structured data segment name; 
that is, in the same declaration with a structure-attribute. The field-attribute 
supplies field-names for some or all of the fields in the structured data seg- 
ment, either directly by listing field-names or indirectly by giving one or more 
field-set-names, or both. 

An example of the use of a field-attribute is: 

OWN 

ALPHAS BLOCKCDCB_SIZE] F I ELD < DCB_F I ELDS > ? 

In this example, the field-attribute associates the field-set-name DCB — 
FIELDS with the data segment name ALPHA. 

Like the field-declaration, the field-attribute can best be explained in the 
context of a complete example of structure declaration and use. Such an 
example is given in Section 11.10.3. 

11.6.1 Syntax 



field-attribute 


FIELD ( { field . set . na me } »- } 


field-name ) 
field-set-name J 


name 
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11.6.2 Restrictions 

Although a field-set-name can appear as a field-attribute parameter in a data 
segment declaration (as the syntax shows), it cannot be used in a structure- 
reference to the data segment. The individual field-names associated with the 
field-set-name must be used instead. 

A field-attribute can be used only in a declaration that also has a structure- 
attribute. 

11.6.3 Semantics 

A field-attribute specifies the set of field-names that may appear in an ordi- 
nary-structure-reference to tj^e data segment declared with the given field- 
attribute. A field-set-name in a field-attribute implies a defined set of field- 
names that may so appear. If no field-attribute is given, then no field-name is 
valid in such a reference. 

1 1 .7 Ordinary-Structure-References 

A structure-reference is used to access a part of a structured data segment. 
The part of the segment that is accessed is determined by the access-actual 
parameters in the structure-reference. For example, a structure-reference for a 
vector has one access-actual parameter that specifies the element of the vector 
to be accessed. 

Three kinds of structure-reference are provided: ordinary, default and general. 
The ordinary-structure -reference is by far the most commonly used form. It 
gives the name of a data segment and relies on the compiler to determine the 
appropriate structure from the declaration of the segment name. A default- 
structure-reference is similar, but the address of the data segment is given by 
an expression, often a preceding ordinary- or default-structure-reference, and 
relies on the compiler to determine the structure from the default structure 
specification given in a switches-declaration or module-switch. A general- 
structure-reference is self contained. It gives all the information necessary for 
the access. 

Suppose the declaration of A is: 

OWN A: VECTOR: 10] 5 

An example of an ordinary-structure-reference is: 

a: , j] 

The compiler uses the declaration of A to find the kind of structure that is 
being accessed. This ordinary-structure-reference is a reference to a VECTOR 
that consists of 10 elements. The structure-body that is declared for VECTOR 
is used in combination with the allocation-actuals in the declaration of A and 
the access-actuals in the structure-reference to determine the field-reference 
for the appropriate element of the vector. 
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Suppose the following set of declarations are given: 

OWN A: VECTOR: 10] i 

SWITCHES STRUCTURE (BLOCK Cl])5 

FIELD FL = [0»0»ZBPVAL/2»0.] » 

FR = CO »7,BPVAL/2 f'^BPVAL/2 >0] 5 

An example of a default-structure -reference is: 

AC .J][FL] 

The compiler processes the initial ordinary-structure-reference, A[.J], as de- 
scribed in the preceding example. The field-reference that results is then used 
as the address part of a subsequent structure-reference. The compiler uses the 
specification of the default structure in the switches-declaration to find the 
kind of structure that is being accessed. In this example the default-structure- 
reference is a BLOCK that consists of one fullword. The structure-body that is 
declared for BLOCK is used in combination with the allocation-actuals in the 
default structure specification in the SWITCHES declaration to determine 
the field-reference for the appropriate field in the j'th element of segment A. 

An example of a general-structure-reference is: 

VECTORCA, Ji 103 

This general-structure-reference is equivalent to the ordinary-structure-refer- 
ence given above. 

Ordinary-structure-references are described in this section. Default- and gen- 
eral-structure-references are described in the next two sections. 



11.7.1 Syntax 



structure-reference 


( ordinary-structure-reference \ 
I default-structure-reference / 
' general-structure-reference / 


ordinary-structure- 
reference 


segment-name [ access-actual ,... ] 


segment-name 


name 


access-actual 


{ field-name \ 
< expression > 
V nothing / 



11.7.2 Restrictions 

A structure-attribute must be associated with the segment-name. 

If field-names are used as access-actuals in the structure-reference, then a 
field-attribute designating those field-names must be associated with the seg- 
ment-name. 
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An access-actual parameter must be given for each access-formal name that 
appears in the structure -body of the associated structure-definition. 

11.7.3 Semantics 

The interpretation of an ordinary-structure-reference is: 

1. Use the segment-name to get the structure-body of the associated struc- 
ture-definition and to get the values associated with each of the alloca- 
tion-names for that segment-name. 

2. If the structure-attribute for the segment did not include the keyword 
REF, then determine the value of the data segment name (which is the 
address of the data segment) and associate that value with the structure 
name. 

If the structure attribute did include the keyword REF, then fetch the 
fullword contents of the segment-name and associate that value with 
the structure name. 

3. If one or more access-actuals is a field-name, replace each field-name 
with its defined sequence of field-component values. This replacement 
may increase the number of access-actual expressions in the resulting 
structure-reference . 

4. Evaluate the access-actual expressions and associate the i'th access- 
actual value with the i'th access-formal name in the structure defini- 
tion. The order of evaluation of the access-actual expressions is not 
defined (see Section 5.1.4). 

5. Evaluate the structure-body using the values associated with each of 
the allocation-formal names, the access-formal names, and the struc- 
ture-name. 

6. Use the resulting expression (which is typically a field-reference) in 
place of the structure-reference. 

11.7.4 Discussion 

An important characteristic of structure-references is that the access-actual 
expressions in a structure-reference are each evaluated exactly once. The 
resulting value is used in the structure-body evaluation in each place that the 
access-formal appears. 

Consider the following declarations: 

EXTERNAL ROUTINE 

X » 
Y t 

f ; 
structure 

XYZCAiB] = 
C53 

(XYZ+X(A)+Y( A) ) 5 
OWN ABC: XYZC4] i 
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Given these declarations, the structure-reference 

ABCCF( ) ] 

is logically equivalent to 

BEGIN 

LOCAL temp; 

TEMP = F( ) 5 

K( *TEMP) + Y< ,TEMP> 

END 

The routine F is called once in the structure-reference ABC[F()] and the 
resulting value is used twice. 

Since structure-references are handled by the compiler in a manner similar to 
macro expansions and they are, in fact, compiled to in-line code, it is natural 
to think of structure-references as macro calls; however, the preceding discus- 
sion shows that the interpretation of the actual parameters is more similar to 
that for routine-calls. 

11.8 Default-Structure-References 

A default-structure-reference is used when an ordinary-structure -reference 
cannot provide the required field-reference. This usage arises when the ad- 
dress of the accessed data segment is an expression, so that the name of the 
data (which is part of an ordinary-structure-reference) is not known. When 
this occurs frequently in a block or module, it can be convenient to give a 
default structure -attribute in a switches-declaration or module-switch to pro- 
vide the structure information to be used for all such occurrences. 

An example of a default-structure-reference has already been given in the 
introduction of Section 11.7. A more extensive example is given in Section 
11.11.7. 

11.8.1 Syntax 



default-structure- 
reference 


address [ access-actual ,... ] 


address 


C primary ) 
( executable-function J 


access-actual 


f field-name \ 
< expression > 
( nothing / 
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11.8.2 Restrictions 

The address of a default-structure-reference must not be the name of a data 
segment declared with a structure-attribute. (If the address is the name of a 
data segment declared with a structure-attribute, then the structure-reference 
is an ordinary-structure-reference and is interpreted as described in Section 
11.7.) 

A default-structure-reference must only occur in the scope of a non-empty 
STRUCTURE switch-item (see Section 18.2). 

An access-actual parameter must be given for each access-formal name that 
appears in the structure-body of the definition of the default structure. 

11.8.3 Semantics 

The interpretation of a default-structure-reference is: 

1. Use the default structure-attribute to get the structure-body of the asso- 
ciated structure-definition and to get the allocation-actual values asso- 
ciated with each of the allocation-names of the structure. 

2. If the default structure -attribute does not include the keyword REF, 
then associate the value of the address of the structure reference with 
the structure-name. If the default structure-attribute does include the 
keyword REF, then fetch the fullword contents of the address value, 
and associate the result with the structure-name. 

3. If one or more access-actuals is a field-name, replace each field-name 
with its defined sequence of field-component values. This replacement 
may increase the number of access-actual expressions in the resulting 
structure-reference . 

4. Evaluate the access-actual expressions and associate the i'th access- 
actual value with the i'th access-formal name in the structure-defini- 
tion. The order of evaluation of the access-actuals is not defined (see 
Section 5.1.4). 

5. Evaluate the structure-body using the values associated with each of 
the allocation-formal names, the access-formal names, and the struc- 
ture-name. 

6. Use the resulting expression (which is typically a field-reference) in 
place of the structure-reference. 

11.8.4 Discussion 

Default-structure-references are very similar to ordinary-structure-references. 
The differences are: 

1. A default-structure-reference uses the structure information established 
in a default structure-attribute, and hence, must occur in the scope of a 
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non-empty STRUCTURE switch-item. In contrast, an ordinary-struc- 
ture-reference uses the structure information associated with the decla- 
ration of a data segment name and is independent of whether or not a 
default structure-attribute is established. 

2. A default-structure-reference permits any field-name to be used as an 
access-actual parameter. (In this respect it is like a general-structure- 
reference, see Section 11.9.) There is no way to specify a default field- 
attribute to go with the default structure-attribute. In contrast, an ordi- 
nary-structure-reference permits only those field-names that are given 
in the field-attribute of the data segment declaration. 

Observe that when an ordinary- or default-structure-reference occurs as the 
address part of another default-structure-reference, the interpretation occurs 
from left to right. That is, a structure-reference of the form 

exp[ actuals ,... ] [ actuals ,... ] 

is equivalent to 

( exp [ actuals ,... ]) [ actuals ,... ] 

Also observe that such a structure -reference is a primary and is interpreted 
before any operators are applied. For example, 

x = • y c l ] c 2 ] is equivalent to x = • < Y c l ] ) c 2 ] 

and 

x = ♦ ♦ y c i ] c 2 ] c 3 ] is equivalent to x = , . < < y c i ] > c 2 ] ) c 3 : 

Consider the following block: 



BEGIN 




SWITCHES STRUCTURE (VECTOR CIO] > 5 




OWN X5 




♦ ♦ ♦ 

x co] = i ; 


! V a 1 i d 


♦ ♦ ♦ 

BEGIN 




SWITCHES STRUCTURE ( ) 5 




♦ t ♦ 

X CO] = 15 


! I n i.' a 1 i d 


+ ♦ ♦ 

END 




♦ ♦ ♦ 

END 





The declaration of X in this example does not associate the structure-attrib- 
ute VECTOR[10] with X. Segment X is a scalar by default and is allocated a 
single full word. 

The first occurrence of X[0], in the fifth line of the example, is a valid default- 
structure-reference. It cannot be an ordinary-structure-reference because no 
structure-attribute is associated with X. The second occurrence of X[0], in the 
tenth line of the example, is invalid because the default structure-attribute is 
empty and, as before, there is no structure-attribute associated with X. 
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As another example, consider the block 

5EGIN 

SWITCHES STRUCTURE ( VECTOR C 100] > 5 

OWN X: BITVECTOR [20] i 

x : . i ] = i ; 
( x ) c , i ] = i ; 

END 

In this example, the structure-reference X[.I] is an ordinary-structure-refer- 
ence because the structure-attribute BITVECTOR[20] is given in the declara- 
tion of X. Thus, the interpretation of the structure-reference uses the 
BITVECTOR structure (and not the VECTOR structure). 

The structure-reference (X)[.I] is a default-structure-reference because (X), 
the base address of the reference, is not a data segment name. The value of 
the expression (X) is, of course, the same as the value of X, but the BITVEC- 
TOR structure-attribute associated with X is lost in the evaluation of the 
expression (X), just as it is in the evaluation of the expressions (X+4) or even 
(X+0). Thus, the interpretation of the structure-reference (X)[.I] uses the 
VECTOR structure (and not the BITVECTOR structure). 

The above examples are not realistic examples of the use of default-structure- 
references; rather they emphasize certain fine points in the distinction be- 
tween ordinary- and default-structure-references. More realistic examples are 
given in the last part of this chapter, Section 11.11.7. 

The above examples also illustrate how it is possible to be confused about 
whether a structure-reference is ordinary or default when the address is a data 
segment name. For this reason, default-structure-references should be used 
cautiously and only when there is a very good reason. 

A default-structure-reference provides no capability that cannot also be 
achieved with a general-structure-reference. It is strictly a notational and 
stylistic convenience. 

11.9 General-Structure-References 

A general-structure-reference is used when an ordinary-structure-reference 
cannot provide the required field-reference. This usage arises in two ways. 
First, a general-structure-reference must be used when the address of the 
accessed data segment is an expression, so that the name of the data segment 
(which is part of an ordinary-structure-reference) is not known. Second, a 
general-structure-reference can be used to access a given data segment using a 
different structure-definition than that which is associated with the name of 
the data segment. 



11-34 Data Structures 



An example of the second use of a general-structure-reference is given in the 
following block: 



BEGIN 
STRUCTURE 

ARRAY C It J 5 M » N] = 
CM*N*XUPOAL] 
(ARRAY+( I*N+J)*XUPUAL) 5 
OWN ALPHA; VECTOR C 200 1 5 



ARRAY [ALPHA »• I *. J5 50 »4 3 



END 



5 



The general-structure-reference interprets the vector ALPHA as a two-dimen- 
sional array according to the structure-declaration for ARRAY. (The declara- 
tion of this two-dimensional array structure is discussed in Section 11.11.3.) 

11.9.1 Syntax 



general -structure - 
reference 


structure-name 

[ access-part 

( ; allocation-actual ,... ) , 
\ nothing J 


access-part 


segment-expression 

( , access-actual ,... ) 
\ nothing ) 


segment-expression 


( expression ) 
\ nothing ) 



The syntactic names structure-name, access-actual and allocation-actual are 
defined in Sections 11.3 and 11.4. 



11.9.2 Restrictions 

If the structure-name appears in the structure-body of the definition of the 
structure-name, then the segment-expression must be non-empty. 

An access-actual parameter must be given for each access-formal name that 
appears in the structure-body of the definition of the structure-name. 

An allocation-actual must be given for each allocation-name that appears in 
the structure-body and that does not have an allocation-default. 
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11.9.3 Semantics 

The interpretation of a general-structure-reference is: 

1. Use the structure-name to get the structure-body for the declaration of 
that name. 

2. If one or more of the access-actuals is a field-name, replace each field- 
name with its defined sequence of field-component values. This replace- 
ment may increase the number of access-actual expressions in the re- 
sulting structure-reference. 

3. Evaluate the segment-expression and associate the value with the struc- 
ture-name in the structure definition. 

4. Evaluate the access-actual expressions and associate the i'th access- 
actual value with the i'th access-formal name in the structure defini- 
tion. 

5. In BLISS-16 or BLISS-32, if an allocation-unit or extension-attribute 
keyword appears as an allocation-actual, replace it by a constant value 
as follows: 



Keyword 


Replaced by 


LONG 
WORD 
BYTE 


4 <= 32 only 

2 

1 


SIGNED 
UNSIGNED 


1 




6. Evaluate the allocation-actual expressions and associate the i'th alloca- 
tion-actual value with the i'th allocation-formal name in the structure 
definition. (Observe that each allocation-actual is a compile-time con- 
stant value.) 

7. Any allocation-formal that does not have a value already associated 
with it from the previous step, but does have an allocation-default value 
specified, is associated with that default value. 

8. Evaluate the structure-body using the values associated with each of 
the access-formals, allocation-formals and the structure-name. 

9. Use the resulting expression (which is typically a field-reference) in 
place of the structure-reference. 

The order of evaluation of the segment-expression and access-actual expres- 
sions is not defined (see Section 5.1.4). 

The interpretation of a general-structure-reference combines the relevant 
parts of the rules for interpretation of an ordinary-structure-reference and the 
structure-attribute for a given data segment. 
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11.9.4 Discussion 

A general-structure-reference of the form 

structure -name [ segment, access ,...■ ; allocation ,... ] 
is equivalent to the following field-reference: 

BEGIN 

BIND base = address 

: structure-name C allocation > . ♦ . ] 5 
base i access >«<« ] 
END field -selector 

where: 

base is an arbitrary unique name created for the purpose of this 

discussion. 

address is the address part of the field-reference in the structure- 

body of the declaration of the structure-name. 

field-selector is the field-selector part of the field-reference in the struc- 
ture-body of the declaration of the structure-name. (As the 
syntax of Sections 11.2 and 11.3 show, a field-selector is 
optional.) 

The BIND declaration is described in Section 14.3. 

As with an ordinary-structure-reference, the parameters of a general-struc- 
ture-reference are evaluated once, and the resulting values can be used more 
than once (see Section 11.7.4). 

Unlike an ordinary-structure-reference, however, any field-name can be used 
as an access-actual of a general-structure-reference. There is no way to desig- 
nate a specific set of field-names that are valid; that is, there is nothing 
analogous to the field-attribute for general-structure-references. 

A general-structure-reference does not include (or need) anything analogous 
to the REF keyword in a structure-attribute. The same effect is accomplished 
by explicitly indicating the extra fetch in coding the segment-expression. 
Consider the following: 



OWN 

A; 
Bs 


VECTOR C 10] i 
REF VECTOR 


INITIAL(A) 1 


» ♦ ♦ 

AC 1] = 11 

VECTOR C A *1 ' 

BCU = 15 
VECTOR C . B »] 


» 103 = 1 

L 1 1 ] = 


5 
1 5 



All four assignments have the same effect; namely, they assign one to the 
second element of A. The first two assignments show the corresponding ordi- 
nary- and general-structure-references for the non-REF structure A. The sec- 
ond two assignments show the corresponding ordinary- and general-structure- 
references for the REF structure B. 
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11.10 Predeclared Structures 



The structures most commonly used in system programming are predeclared 
in BLISS. The use and interpretation of each of these structures has already 
been introduced in Chapter 3 and used in examples. This section presents the 
definition of each of these structures. 

The four predeclared structures provide no capability that is not available by 
explicitly coding the structure-declarations given in the following sections. 
They are predeclared in BLISS as a convenience and to foster the use of 
uniform names for these common structures. 

The predeclared structures are the following: 

Structure-Name Usage 

VECTOR A vector of signed or unsigned elements of uniform size 

(bytes or words in BLISS-16; bytes, words, or long- 
words in BLISS-32; and words in BLISS-36) 

BITVECTOR A vector of one-bit elements 

BLOCK A sequence of varying-sized fields 

BLOCKVECTOR A vector of blocks. 

The declaration and use of the predeclared BLOCK structure is discussed 
here in detail because of its fundamental nature (along with VECTOR, dis- 
cussed previously). The BITVECTOR and BLOCKVECTOR structures are 
discussed more briefly because they are straightforward variations of the 
VECTOR and BLOCK structures. 

11.10.1 VECTOR Structures 

A VECTOR structure is a sequence of elements of the same size. The number 
of elements, n, is the extent of the vector. The elements are numbered from 
to n-1. The generalized form of the structure-declaration is: 

STRUCTURE 

VECTOR: I 5 N > UNIT = 7,UPVAL t EXT=03 = 
CN*UNIT] 
( VECT0R+ I *UN I T )< > 7.BPUN I T*UN I T »EXT > 5 

When this generalized declaration is made dialect specific, the resulting (ac- 
tual) structure-declaration of VECTOR in each dialect is as follows: 

• In BLISS-16 — 

STRUCTURE 

VECTOR: I 5 N» UNIT=2, EXT =0 3 = 
CN*UNIT3 
(VECT0R+I*UNIT)<0 »8*UNIT tEXT>» 

• In BLISS-32 — 

STRUCTURE 

vector: i; n, unit=4» ext=03 = 

CN*UNIT3 

(VECT0R+I*UNIT)<0 »S*UNIT tEXT>i 
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• In BLISS-36 — 

STRUCTURE 

VECTOR CI 5 IM] = 
EN] 
(VECTOR+I )<0 ,3G>» 

The formal names of the structure-declaration have the following meanings: 

Formal-Name Meaning 

I The number of the element to be referenced 

N The number of elements in the vector 

UNIT The number of addressable-units in each element. The 

valid values vary with the target system: 1 or 2 for 
BLISS-16, and 1 through 4 for BLISS-32. (Since the only 
valid value would be 1 in BLISS-36, the formal-name 
UNIT is omitted in that dialect.) The default value, 
%UPVAL, implies a fullword. 

EXT The sign-extension rule to be used for fetching elements. 

The valid values are and 1. The default is 0, that is, 
unsigned. (Note that sign-extension of a fullword is not 
meaningful, thus the formal-name EXT is omitted in 
BLISS-36.) 

Example uses of this structure as structure -attributes in declarations are: 

Example Interpretation 

v E c t o r c i o i A vector of 10 fullwords 

v e c t o r c l o t w o R D ] A vector of 10 unsigned words in BLISS-16/32 

VECT0RCZ0fBYTE»siGNED] A vector of 20 signed bytes in BLISS-16/32 

REFVECT0RC53 A reference to a vector of 5 fullwords 

VECT0RC20f33 A vector of 20 three-byte elements, in 

BLISS-32 only. 

11.10.2 BITVECTOR Structures 

A BITVECTOR is a sequence of one-bit elements that are densely packed in 
storage. The number of elements, n, is the extent of the bitvector. The ele- 
ments are numbered from to n-1. The generalized form of the structure- 
declaration is: 

STRUCTURE 

BITVECT0RCI5 N] = 

C (N+C/.BPUNIT-1 ) ) /5T.BPUNIT] 
(BITVECTOR+I/XBPUNITKI MOD %BPUNIT » 1 »0> S 

The actual, dialect-specific forms of this structure-declaration are as follows: 

• In BLISS-16 — 

STRUCTURE 

BITVECTORCI 5 N] = 
C ( (N+7)/8) ] 
<BITVECTOR+< I"-3> XI AND 7 .1 *0> 5 
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• In BLISS-32 the following variation is used to take advantage of the less 
restrictive field-references for better code quality — 

STRUCTURE 

BITVECTORCIi N] = 
C (N+7)/8] 
BITYECTOFKI »1>5 

• In BLISS-36 — 

STRUCTURE 

BITVECTORCIi N ] = 
C (N+35)/3G] 
(BITVECT0R+I/3BX I MOD 36»1»0>» 

The formal names of this structure have the following meaning: 
Formal-Name Meaning 

I The number of the element to be referenced 

N The number of elements in the vector 

Example uses of this structure as structure -attributes in declarations are: 

Example Interpretation 

ref bitvectorc8] A reference to a vector of 8 one-bit elements 
b i t u e c t o r c b o ] A vector of 60 one-bit elements 

Observe that the second data segment would occupy 8 bytes of PDP-11 or 
VAX-11 storage, and would leave the four high order bits of the last byte 
unused. On the DECSYSTEM-10/20 the first data segment would occupy one 
word with 28 high order bits unused; the second would occupy two words with 
12 high order bits of the second word unused. 

11.10.3 BLOCK Structures 

A BLOCK structure is a sequence of components. The individual components 
of a block can be of various sizes. The generalized form of the structure- 
declaration is: 

STRUCTURE 

BL0CKE0, P> S» E5 BS t UN I T = XUPUAL ] = 
EBS*UNIT] 
( BLOCK + 0*UNITXP »S »E>i 

The actual, dialect-specific forms of this structure-declaration are as follows: 

• In BLISS-16 — 

STRUCTURE 

BLOCKCOt P» St E5 BS * UNIT=23 = 
CBS*UNIT] 
(BLOCK + 0*UNITXP »S fE>i 

• In BLISS-32 — 

STRUCTURE 

BL0CKC0* P, Si Ei BS » UNIT=4] = 
CBS*UNIT] 
( BLOCK + 0*UNITXP »S »E> i 
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• In BLISS-36 — 



STRUCTURE 

BLOCKCO, P» S> Ei BS3 = 
CBS] 
( BLOCK + OXP »S »E>» 

The formal names of this structure have the following meanings: 

Formal-Name Meaning 

O The offset to the addressable-unit in which the field be- 

gins 

P The bit offset from the addressable-unit to the field be- 

ginning 

S The size of the field in bits. Valid values are to 

%BPVAL 

E The extension flag. Valid values are for zero-extension 

and 1 for sign -extension 

BS The number of allocation units needed to represent the 

block, i.e., the block size 

UNIT The size of the allocation-unit and offset in terms of ad- 

dressable units. Valid values vary with the target system: 
1 or 2 for BLISS-16, 1 through 4 for BLISS-32, and 1 only 
in BLISS-36 (the formal-name UNIT is omitted in that 
dialect). The default is %UPVAL, that is, a fullword. 

Blocks are conventionally allocated in fullword units for most efficient opera- 
tion of the hardware. (Using default fullword allocation also facilitates tran- 
sportability of BLISS programs.) 

11.10.3.1 A Typical Byte-Oriented BLOCK Structure — An example of a typi- 
cal block on a byte-oriented target system (PDP-11 or VAX-11) is considered 
in detail in the following paragraphs. The block is named ALPHA and has five 
components, named A, B, C, D, and E. The VAX-11 target system and 
BLISS-32 dialect are assumed for the purposes of this example as they pro- 
vide the richest basis for explanation of the underlying BLISS structure mech- 
anisms. (A BLISS-36 example would be somewhat simpler since addressable 
byte boundaries are not considered. Analogous code fragments for BLISS-36 
are shown in this discussion where appropriate.) 

The layout of the example block in VAX-11 storage is: 



DCB 










A.32. 


D.19 


C,5 


B.8 


E.32 



:ALPHA 



Data Structures 11-41 



This diagram uses the notation introduced at the beginning of this chapter, in 
Section 11.1.2. 

The name DCB refers to the layout of the fields relative to the starting ad- 
dress of the block. Thus there could be more than one DCB block in storage at 
a given time, one at ALPHA and others at other addresses. 

The block is divided into five components, and the name and size are given for 
each component. Component A contains 32 bits and occupies the four bytes 
whose addresses are ALPHA through ALPHA+3. Component B contains 8 
bits and occupies the byte at ALPHA+4. Component C contains 5 bits and 
occupies the 5 low-order bits of the byte at ALPHA+5. Component D contains 
19 bits and occupies the remaining bits of the byte at ALPHA+5 as well as the 
next two bytes. Component E occupies the next longword. 

1 1 .10.3.2 BLOCK Field-References — Each component of a block has a field- 
reference. The field-references for DCB are: 

Component Field-Reference Analogue For BLISS-36 

A of ALPHA ( AL PH A + X 1 32 f > ( AL PH A + ) < 1 36 1 > 

B of ALPHA ( ALPHA+4 ) < >B »0 > ( ALPHA+ 1 ) < »S »0 > 

C Of ALPHA ( ALPHA+4 X 8 >5 >0> < ALPHA+1 KB >5 »0> 

D Of ALPHA < ALPHA + 4 X 13 ,13 »0> ( ALPHA+1 )< 13 »23 »0> 

E of ALPHA ( AL PHA + 8 K > 32 > > ( AL PH A + 2 X * 3G * > 

As a specific example of access to DCB, consider the field-reference for com- 
ponent D of ALPHA. This expression is interpreted by locating the byte whose 
address is (ALPHA+4) and then applying the field-selector <13,19,0> at that 
position in memory. The field-selector starts at the low-order (rightmost) bit 
of the designated byte, then skips 13 bits (first parameter) to the left, then 
selects the next 19 bits (second parameter), and, finally, applies unsigned 
extension (third parameter) if the access is a fetch. 

The field-references given in the table reflect a bias towards full words. That 
is, if ALPHA is a fullword address, then the expressions (ALPHA+4) and 
(ALPHA+8) are also fullword addresses. This bias is natural for VAX-11, but 
it is not essential. An alternative field-reference for component D that does 
not show this bias is: 

(ALPHA+5X5fi9tO> [No analogue in BLISS-36] 

This field-reference is different from that given previously for D, but it selects 
the same bits of storage. 

Any of the field-references can be used for either a fetch or a store operation. 
For example, to place the value 7 in component D of ALPHA, write: 

( ALPHA+4 X 13 > 13 »0> = 7 

11.10.3.3 BLOCK Allocation — A specific block data segment is allocated by 
means of a BLOCK structure-attribute. The attribute provides values for the 
allocation-formals of the BLOCK structure-declaration. 
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The following declaration allocates storage for the DCB block named ALPHA: 

OWN 

ALPHA: BL0CKC3 ,4] 5 

The structure-attribute in this example is BLOCK[3,4], and it provides the 
values 3 and 4 for the allocation-formals N and UNIT, respectively. When 
storage is allocated for ALPHA, the structure-size expression in the declara- 
tion of BLOCK is evaluated. That expression is N*UNIT and its value is 
therefore 12. Thus 12 bytes of storage (3 fullwords) are allocated for ALPHA. 

An equivalent declaration of ALPHA is: 

OWN 

alphas block c 3 ] ; [Also valid in BLISS-36] 

In this declaration, the structure-attribute does not give a value for UNIT, so 
the default value is used. (This declaration results in the allocation of three 
fullwords in BLISS-36 also, whereas the prior version would not be valid in 
that dialect.) 

Yet another equivalent declaration is: 

LITERAL 

DCB_SIZE = 35 
♦ » ♦ 
OWN 

ALPHA; BLOCKCDCB_SIZE] 5 

This example uses a literal-name instead of a numeric-literal to provide the 
value of the allocation-formal N. This practice is always desirable, and is 
especially so when ALPHA is one of several data segments of the same form. 
The use of the name-DCB_SIZE tells the reader explicitly that ALPHA will 
eventually be used for the block diagrammed at the beginning of this section. 

11.10.3.4 BLOCK Structure-References — A specific component of a data 
block is accessed by means of a structure-reference. The structure-reference 
begins with the name of the data segment and then gives values for the four 
access-formals of the BLOCK structure declaration. 

The following example ends by assigning 7 to component D of ALPHA: 

LITERAL 

DCB„SIZE = 35 
OWN 

ALPHAS BLOCKCDCB„SIZE] 5 

4 t ♦ 

ALPHA CI »13 » 19 »0] = 7 5 

The structure-reference in this example is interpreted as follows. First, make 
a copy of the structure-body of the declaration of BLOCK. That structure- 
body is: 

( BLOCK + 0*UN IT )<P >S ,E> 

Next, replace the "zero'th formal-name", BLOCK, with ALPHA, giving: 

(ALPHA + 0*UNITXP fS »E> 
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Next, replace the allocation-formal UNIT with 4, giving: 

(ALPHA + 0*4KP *5 #E> 

Finally, replace the four access-formals, 0, P, S, and E, with the correspond- 
ing access-actual parameters, 1, 13, 19, and 0, giving: 

(ALPHA + 4K13 »19 »0> 

This is the same as the field-reference given for component D in Section 
11.10.3.2. 

11.10.3.5 BLOCK Field-Declarations — The reference to component D of AL- 
PHA is improved by the use of the BLOCK structure-name, but it still re- 
quires a list of integer parameters, [1,13,19,0], that bears no obvious relation to 
the description "component D of DCB". 

This problem could be solved by defining a macro, such as: 

MACRO 

DCB_D = 1,13*19,0 Z\ 

However, BLISS provides a special feature, the field-declaration, for this 
purpose. 

The following program fragment shows the complete mechanism for handling 
the block ALPHA: 

LITERAL 

DCB_SIZE = 35 
FIELD 

DCB_FIELDS = 
SET 

DCB_A = CO ,0 ,32 ,0] , 
DCB_B = [1,0,8,0], 
DCB_C = CI ,8 ,5 ,0] * 
DCB-D = Cl»13.19 ,0] , 
DCB„E = C2»0,32,0] 
TESi 
MACRO 

DCB = BL0CKCDCB_SIZE] F I ELD ( DCB_F I ELDS ) 7,5 
OWN 

ALPHA: DCBi 

ALPHACDCB_D] = 75 

The field-declaration defines the four-integer code for each component and 
also gives a name, DCB FIELDS," to the five field-names thus declared. 

The declaration of the macro-name DCB is the final convenience; it permits 
the block layout that is associated with ALPHA to be designated by a single 
name, DCB. 

When the macro-call on DCB is expanded, the declaration of ALPHA be- 
comes: 

OWN 

ALPHA: BL0CKCDCB_SIZE] F I ELD ( DCB_F I ELDS ) 5 

The field-attribute allows the five field-names associated with DCB 

FIELDS to be used in structure-references for ALPHA. 
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11.10.4 BLOCKVECTOR Structures 

A BLOCKVECTOR structure is a vector of blocks. The number of elements, 
n, is the extent of the vector and the size of each element is the size of a single 
block. The elements are numbered from to n-1. The structure-declaration 
for BLOCKVECTOR in each dialect is: 

• InBLISS-16 — 

STRUCTURE 

BLOCKVECTORCI t 0, Pi S» E» N» BS » UNIT=2] = 
CN*BS*UNIT] 
<BLQCKVECTOR+( I *BS + ) *UN I T )< P »S ,E> 5 

• In BLISS-32 — 

STRUCTURE 

BLOCKVECTOR: I , 0, P» S» E5 N> BS » UNIT=4] = 
CN*BS*UIMIT] 
(BL0CKVECT0R+( I *BS + ) *UN I T X P ,S »E> 5 

• In BLISS-36 — 

STRUCTURE 

BLOCKVECTORC I » 0» P> S» Ei Ni BS] = 

:n*bs] 

( block vect0r+( i*bs+0> )<p ,s »e>i 

The formal names of the structure-declaration have the following meanings: 

Formal-Name Meaning 

I The number of the block element. Valid values are 

through N-1 

The offset to a field. Valid values are through BS-1 

P Bit offset from the addressable-unit to the beginning of 

the field 

S Size of the field in bits. Valid values are through 

%BPVAL 

E Extension rule. Valid values are for zero-extension and 

1 for sign -extension 

N The number of block elements in the vector 

BS The number of allocation-units in each block element 

UNIT The number of addressable-units in the allocation-unit 

The BLOCKVECTOR structure is a combination of the allocation and access 
definitions from the BLOCK and VECTOR structures. 

Using this structure, a declaration of a vector of DCB blocks (used as an 
example of the BLOCK structure in section 11.10.3) is written: 

ONN XXXs BLOCKVECTOR: 100 >DCB_S I ZE] F I ELD ( DCB_F I ELDS ) 5 

This declaration allocates storage for 100 DCB blocks, each of which is three 
fullwords in size. 
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If the contents of a variable J is 2 then 

.XXXC .J >DCB_D] 

fetches the value of the D field of the third block in the vector. 

Observe that the field-declaration used with the block discussed in Section 
11.10.3 is used with the blockvector discussed here. 
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The predeclared structures described in the previous section are included in 
BLISS because they occur frequently in many types of programs. However, 
they are only a sample of the wide range of structures that can be defined 
using the structure declaration. This section sketches some additional struc- 
tures that illustrate some of the other possibilities. 

To minimize the complexity of the example structures presented, only full- 
word versions of the structures are defined. These examples could be aug- 
mented in a variety of ways to be more flexible. Also, the structure-declara- 
tions are written in parameterized, transportable form (using the predeclared 
literal %UPVAL) such that they are valid in all dialects. 

11.11.1 "One-Origin" Vector Structures 

The definition of vector presented previously numbered the elements of the 
vector from to n-1, where n is the number of elements of the vector. In some 
applications, it is more natural to number the elements from 1 to n instead. 

A structure that accomplishes this is: 

STRUCTURE 

VECTOR 1C I 5 N] = 
CN*ZUPVAL] 
(VECT0Rl+< 1-1 )*ZUP','AL) ; 

This structure differs from the VECTOR structure previously presented in 
that 1 is subtracted from the element number before the offset relative to the 
base of the vector is computed. 

11.11.2 "Bounds Checking" Vector Structures 

On occasion, particularly during debugging, it is desirable to perform validity 
checking of the access-actuals of a structure-reference. For the VECTORl 
structure just given, bounds checking can be accomplished as follows: 

STRUCTURE 

VECT0R1CHKCI i N] = 
ClNHaUPVAL] 
BEGIN 

local t; 

t = i ; 

if ,t lss 1 or ,t gtr n 

THEN 

BEGIN 

ERROR ( . T) ? 
T = 1 ; 

end; 

VECTOR lCHK+< .T-l )*%UPVAL 

end; 
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This structure calls a routine ERROR for those cases in which the value of I is 
not in the valid range of 1 through N inclusive. 

11.11.3 Two-Dimensional Array Structures 

A zero-origin two dimensional array structure can be defined as follows: 

STRUCTURE 

ARRAY CI t J 5 M » N] = 
CM*N*'ZUP>.'AL] 
<ARRAY+< I*N + J)*'/.UPVAL) 5 

This structure stores elements in "row-order" as in PL/I. 

A similar structure that stores elements in one-origin "column-order", as in 
FORTRAN, can be defined as follows: 

STRUCTURE 

ARRAYBYCOLEI » Jl M. N] = 
CM*N*XUPUAL3 

(ARRAY+( ( J-i )*M+( 1-1 ) >*XUPYAL) 5 

This structure differs from the previous example in the following ways: 

• I is replaced by 1-1 and J is replaced by J-l to get one-origin numbering 
of the elements. 

• I and J are interchanged in the structure-body, as are M and N, to get 
column-ordering instead of row-ordering. 

11.11.4 Symmetric Array Structures 

A symmetric array is a square array in which the contents of A [I, J] is equal to 
the contents of A[J,I]. For such an array, it is not necessary to allocate storage 
for the entire array. 

A symmetric 3-by-3 array can be diagramed as follows: 

j ^ 



(1,1) 


(1.2) 


(1,3) 




(2,2) 


(2,3) 






(3,3) 



The number of elements needed to represent a symmetric array is: 

n * ( ri + 1 ) / 2 

where n is the number of elements in each dimension. In the 3-by-3 example 
above this gives 3*4/2, or 6, elements. 

The storage for such an array can be allocated with the elements in the 
following order: 



( 1 1 1 ) » ( 1 tZ) t (2tZ) 



1 »3) » (2 ,3) » (3 »3) 
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If j is greater than or equal to i then the linear position of the (i,j) element in 
the storage sequence is given by the formula 

J*< J-l ) /2+i 
In the 3-by-3 example above, the position of the (2,3) element is 

3*<3-l)/2+2 = 5 

That is, element (2,3) is the fifth element of the linear sequence. 

This analysis can be incorporated into a structure declaration for symmetric 
arrays as follows: 

STRUCTURE 

SYMARRAYC It J 5 M] = 

C (M*(M+1 ) /2>*7,UP0AI_] 
(SYMARRAY-XUPOAL+ 
< IF J GTR I 
THEN 

J*( J-l ) /2+I 
ELSE 

I*( 1-1 )/2+J 
)*'/.UPOAL 
) 5 

Declaration and use of this structure is the same as for an ordinary two- 
dimensional one-origin array. For example, 

OWN SYMX : SYMARRA Y E 1 0' 1 1 ] 5 

declares and allocates a 10-by-10 symmetric array named SYMX. It occupies 
55 full words of storage. 

The sum of the 100 "logical" elements of the array can be computed as shown 
in the following: 

SUM = 5 

INCR I FROM 1 TO 10 DO 

I NCR J FROM 1 TO 10 DO 

SUM = .SUM + . SYMXC ,I.,J]i 

11.11.5 Non-Continuous Block Structures 

The predeclared definition of the BLOCK structure given previously assumes 
that all of the fields of the block are contiguous in memory. In some cases this 
might not be possible or desirable. For example, a storage management sub- 
system might be in use that provides only a fixed-size block of memory. In 
such a circumstance it may still be desirable to reference a "logical block" as 
an entity even though it might be represented using more than one physical 
block of memory. 

The following structure illustrates a way to achieve this: 

STRUCTURE 

LBL0CKE0 i P f S » E f I] = 

(CASE I FROM TO 1 OF 
SET 

CO]: (LBL0CK + 0*/f,UP0AL) 5 
[ 1 ] s ( .LBLOCK + CHaUPyAL) 5 
TES 
) < P » S » E > ; 
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Since this structure is only intended to be used with dynamically allocated 
memory, the definition does not contain a structure-size expression. 

A typical declaration of a data segment that points to an instance of this 
structure is: 

OWN XPTR: REF LBLOCK 5 

To understand this structure, consider the following diagram: 



XPTR 



E 


F 


H 


G 


1 


^ 0/ Dr»W A I i_:j._ 






- /Ul_»l V 









LBLOCK Organization 

The diagram illustrates a logical block consisting of 9 fields named A through 
I. The logical block is represented as two physical blocks. Each physical block 
consists of four fullwords, the assumed fixed-size storage management unit. 
The arrows indicate fields that contain the address of the first block and of the 
remainder of the logical block. 

The first physical block is like the BLOCK structure described in Section 
11.10.3. However, the access formal list for the LBLOCK structure includes 
an additional formal name, I, that the BLOCK structure did not have. This 
formal name is used in the structure -body to choose one of two expressions as 
the structure address expression. 

The field-name for A is defined as follows: 



FIELD A 



[1 »0 »'/,BPVAL/2 »1 »0] 5 
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When used in a structure -reference to XPTR, the last in this definition 
causes the first case-line of the structure-body to be used, and thus the refer- 
ence 

XPTR CA] 

is like a BLOCK reference. 

A field in the second physical block, such as F, is defined using a 1 as the last 
value, as in: 



FIELD F 



C 1 ,0 »7,BPVAL ,1 »1 ] ", 



The last 1 in this definition causes the second case-line to be used. Examina- 
tion of the second case-line shows that it is just like the first except that the 
contents of the first fullword of the first physical block is used as the base for 
applying the offset, position, size and extension values. 

A reference to this field is written in the same way as a reference to the A field, 
that is, as: 

XPTRCF] 

The "extra indirection" used to reference this field is "hidden" in the struc- 
ture and field definitions used to define the logical structure. 



11.11.6 Partially Overlayed Structures 

Some programming applications require data structures that are similar with 
respect to some, but not all, of their fields. 

For example, consider the symbol table of a compiler. The table must accom- 
modate different kinds of identifiers (symbols), and has a different kind of 
block for each kind of identifier. However, in order to make the table useful, 
some fields will appear in all blocks of the table. One such common field will 
be the "type field", which specifies which kind of identifier a given block 
represents. 

As another example, consider the table of device control blocks in an opera- 
ting system. Once again, the table must have different kinds of blocks, one 
kind for each kind of device; and, once again, some fields will appear in all 
blocks of the table. In this example, the common fields might be the priority 
level, a pointer to a queue of operations, and a device type code. 

As a basis for illustration, consider the following diagram: 



TYP 



LEN 



NAME_PTR 



VALUE 



^§^ 

$$$$^ 


TYP 


LEN 


NAME_PTR 


Q 


Z 


LINK 



BLOCK Type 1 



BLOCK Type 2 
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The diagram shows two different blocks that share some common fields, 
namely: LEN, TYP, and NAME_PTR. Each block also has fields that are 
not common with the other block; indeed, the blocks are not even the same 
size. 

The following declarations illustrate one way to code the definitions of these 
two blocks, using BLISS-36 as the sample dialect: 

FIELD 

COM_FLDS = 
SET 

LEN = CO ,0 ,12 ,0] , 
TYP = CO ,12 ,12 ,03 , 
NAME-PTR = CI ,0 ,36 ,0 3 
TES , 

TYP1_FLDS = 
SET 

F = CO ,24 ,12 fO] * 
VALUE = C 2,0,36,0 3 
TES * 

TYP2_FLDS = 
SET 

Z = C 2 , > 1 S , 3 , 
Q = C2 ,18 ,18,13, 
LINK = C3 ,0,36,0 3 
TES 5 

MACRO 

TYP1_BL0CK = BL0CKC3] F I ELD ( C0M_FLD5 ,TYP 1 „FLDS ) It 
TYP2-BL0CK = BLOCKC43 FIELD ( COM-FLDS »TYP2_FLDS ) Zi 

The field-declaration defines three sets of fields: 

COM FLDS, for fields that are common to both types of block, 

TYP1 FLDS, for fields that are specific to the first type of block, and 

TYP2 FLDS, for fields that are specific to the second type of block. 

The macro-declaration defines two macros, one for each kind of block; the 
expansions give the attributes appropriate for each kind of block. 

These macro-names can be used in data declarations such as: 

OWN 

STARTUP: TYP1_BL0CK5 
LOCAL 

PTRs REF TYP2-BL0CK ! 

Observe that in the declaration of PTR (as LOCAL) the structure-attribute is 
REF BLOCKI4], where REF is given explicitly and BLOCK[4] results from 
the expansion of TYP2_BLOCK. If BLOCK[4] and FIELD (COM_ 
FLDS,TYP2 FLDS) had been given in the opposite order in the macro defi- 
nition of TYP2 BLOCK, then additional macro definitions would be needed 

in order to declare data segments with REF structure-attributes. 
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The definition technique shown above has two advantages: 

1. The common definition information is given only once, thereby avoiding 
the possibility of clerical errors in giving the same information in multi- 
ple field-set definitions. 

2. Depending on specific details, changes or additions to the common 
fields can be made in one place, which is easier and more reliable than 
making corresponding changes in many places. 

11.11.7 General Purpose Structures for Default Structure 
References 

Some programming applications involve complicated data structures using 
blocks of various types connected together by pointers. If the nature of the 
application involves frequent access to blocks related to a given block by 
"following pointers", there may well be notational advantages to using a 
default structure (see Sections 11.8 and 18.2). 

To illustrate this, first consider how an example might be coded without using 
default structures. Suppose the following block is being used to represent a 
node in a tree structure, such as might be used for expressions in a compiler. 



OP 



LEFT_OPND 



RIGHT_OPND 



The op field is used to contain a code for the kind of arithmetic operator 
represented, and the LEFT__OPND and RIGHT__OPND fields are used to 
contain addresses of other such nodes. 

A routine to compare the OP fields of the two subnodes of a given node for 
equality might be coded as follows: 

ROUTINE COMPARE_SUBOPS(NODE> = 

BEGIN 

MAP NODE: REF TREE F I ELD ( TREE-F I ELDS ) 5 

LOCAL 

L_PTR: REF TREE F I ELD ( TREE_F I ELDS ) * 
R_PTR: REF TREE F I ELD ( TREE_F I ELDS ) 5 

L_PTR = .NODECLEFT_OPND] ; 

R_PTR = ♦NODECRIGHT_OPND] 5 

IF ,L_PTRCOP] EOL ,R_PTRCOP] 

THEN 

. . . 3 ! Actions if subnodes have same OP value 

END! 

The structure and field name definitions assumed in this example should be 
obvious from earlier examples and are not shown. 
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The same effect can be achieved using a default structure as follows: 

ROUTINE COMPARE-SUBOPS1 (NODE) = 
BEGIN 

SWITCHES STRUCTURE(REF TREE)? 

IF .NODECLEFT-OPNDJtOP] EOL . NODE C R I GHT_OPND 1 C OP 3 
THEN 

♦ ♦ . 5 ! Actions if subnodes have same OP value 
END? 

This second version is slightly shorter. It is also more suggestive of the "logi- 
cal" access being performed because intermediate assignments are not needed 

simply to obtain a data segment name (such as L PTR in the first version) 

that is declared with the appropriate structure properties for each step along 
the path of access. 

Observe that the default structure in this example is a REF structure. This 
means that each step in the access path necessarily makes a fetch to obtain 
the base address for the next field access. 



Data Structures 11-53 



Chapter 12 Routines 



12.1 Ordinary-Routine-Calls 12-1 

12.1.1 Syntax 12-3 

12.1.2 Restrictions . . 12-3 

12.1.3 Semantics 12-4 

12.1.4 Pragmatics 12-4 

12.2 General-Routine-Calls 12-5 

12.2.1 Syntax 12-5 

12.2.2 Restrictions 12-6 

12.2.3 Semantics 12-6 

12.3 Routine-Declarations 12-6 

12.3.1 Syntax 12-7 

12.3.2 Semantics 12-7 

12.4 Ordinary-Routine-Declarations 12-7 

12.4.1 Syntax 12-9 

12.4.2 Restrictions 12-10 

12.4.3 Defaults 12-10 

12.4.4 Semantics 12-10 

12.4.5 Pragmatics 12-11 

12.4.5.1 Parameter Passing 12-11 

12.4.5.2 Allocation of Formal-Name Data Segments 12-13 

12.4.5.3 Attributes for Formal-Names 12-13 

12.4.5.4 Computed Routine Addresses 12-13 

12.5 Global-Routine-Declarations 12-14 

12.5.1 Syntax 12-15 

12.5.2 Restrictions 12-15 

12.5.3 Defaults 12-15 

12.5.4 Semantics 12-16 

12.6 Forward-Routine-Declarations 12-16 

12.6.1 Syntax 12-16 

12.6.2 Restrictions 12-17 

12.6.3 Semantics 12-17 

12.7 External-Routine-Declarations 12-17 

12.7.1 Syntax 12-17 

12.7.2 Restrictions 12-18 

12.7.3 Semantics 12-18 



Chapter 12 
Routines 



Routines are the logical units from which a program is built. Each routine 
describes a portion of the program that is relatively complete and independ- 
ent. The design of BLISS permits a routine to have its own block structure 
and local data. 

A program has a single main routine (see MAIN module-switch, Section 19.2). 
The main routine controls the computation, but it can delegate parts of the 
computation to subordinate routines. Each subordinate routine can, in turn, 
delegate part of its computation to its own subordinate routines. A routine can 
also call an external routine (one defined outside of its own block or module) 
to perform a commonly needed function, for example. 

The use of routines has two sides: the calling of routines and the declaration of 
routines. The first two sections of this chapter describe routine-calls. The 
remaining five sections describe routine-declarations. 

The linkage-declaration, which controls the instruction sequence generated 
for a call on a given routine, and the register- management discipline used 
within the routine, is described in Chapter 13 along with other linkage-related 
declarations. 



12.1 Ordinary-Routine-Calls 



A routine-call causes the execution of a routine that has been declared as part 
of the same module or some other BLISS module, or of a program written in 
another language. 
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Two kinds of routine-calls are provided: ordinary and general. The ordinary- 
routine-call is by far the most commonly used form: it gives the name of a 
routine and relies on the compiler to determine, from the declaration of the 
named routine, the appropriate linkage (or calling sequence). 

A general-routine-call is self-contained. It gives all of the information needed 
for calling the routine. 

An example of an ordinary-routine-call is given in the following program 
fragment: 

OWN 

A t 

B 5 
EXTERNAL ROUTINE 

RFACT5 



A = RFACT( ,B) 
END 

The RFACT routine is declared in another module. The function of the rou- 
tine is to determine the factorial of a given parameter. The result is the value 
of the routine; therefore, the routine does not have a NO VALUE attribute. 
The routine-call RFACT(.B) causes the contents of input-actual-parameter B 
to be passed to the factorial routine and the returned result to be assigned to 
location A. (The routine RFACT declaration is given in Section 12.4.) 

In the example, the routine-call is used to pass an input-parameter; however, 
output-parameters may also be passed. When this is done, each output-ac- 
tual-parameter is treated like .the left-hand side of an assignment expression 
defining where an output-register value (from the called routine) is to be 
stored. 

Output-parameters permit a routine to return results that are larger than a 
BLISS value or to return several values at once. For example, a double- 
precision floating point value can be returned in RO and Rl. 

In the routine-call syntax, output-parameters follow input-parameters and 
are separated by a semicolon (;). 
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12.1.1 Syntax 



routine-call 


( ordinary-routine-call ) 
\ general-routine-call J 


ordinary- 
routine-call 


routine-designator 

/ ( input-actual-parameter ,... ) 
( nothing J 

( ; output-actual-parameter ,... ) x 
( nothing J 


routine-designator 


primary 


input- 
actual-parameter 


( expression ) 
( nothing J 


output- 
actual-parameter 


( expression ) 
\ nothing ) 



MA. 2 Restrictions 

The number of input-actual-parameters in a routine-call must agree with the 
number of input-formal-parameters in the routine-declaration. (This restric- 
tion can be relaxed through use of the linkage-functions described in Section 
13.6.) 

The value of each input-actual-parameter must be consistent with the context 
in which the corresponding input-formal-parameter is used in the routine 
declaration. 

An output-actual-parameter may be any expression, including an undotted 
register-name qualified by position, size, and sign-extension information (i.e. 
field-reference). 

The number of output-actual-parameters must be less than or equal to the 
number of output-formal-parameters specified in the routine declaration. 

An output-actual-parameter must not be specified if a corresponding output- 
parameter-location register is not specified in the linkage. 
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The evaluation of the routine-designator must yield the value of a name that 
has been declared ROUTINE. 

The linkage of the routine-designator (determined as described in Section 
12.1.3) must be the same as the linkage-attribute in the declaration of the 
routine that is called. 

A linkage-name defined with the linkage-type INTERRUPT or RSX_AST 
may not be used in a general-routine-call. 

The order in which the routine-designator and actual-parameters are evalu- 
ated is as follows: Input-actual-parameters are evaluated prior to the routine 
call, and output-actual-parameters are evaluated when the routine returns to 
the caller. 



12.1.3 Semantics 

An ordinary-routine-call is interpreted as follows: 

1. Evaluate the routine-designator and the actual-parameters. 

2. Determine the linkage to be used with the routine-designator. If the 
routine-designator is a routine-name, then the linkage is given by the 
linkage-attribute (explicit or default) in the declaration of the routine- 
name. Otherwise, the linkage is given by the linkage-name established 
in a LINKAGE switch or, if no LINKAGE switch applies, the linkage is 
the default linkage-name for the dialect in use (BLISS for BLISS-16/32; 
BLISS36C for BLISS-36). 

3. Associate the actual-parameters with the formal-parameters of the rou- 
tine called. The value of the i'th actual-parameter becomes the content 
of the i'th formal-parameter. 

4. Create a stack frame. The kind of stack frame and the details of its 
organization depend on the linkage of the routine. 

5. Evaluate the routine-body. 

6. Delete the stack frame. 

7. Evaluate the output-actual-parameter expressions and assign the 
returned output-register values to the appropriate output-actual- 
parameters. 

8. If a value is returned, use that value as the value of the routine-call. 

The linkage used in a routine-call does not affect the semantics of the call, but 
instead affects the details of how the call is carried out. Linkages are de- 
scribed in Chapter 13. 

12.1.4 Pragmatics 

An input-actual-parameter in a routine-call can be a %REF standard func- 
tion. This function is especially designed for use in routine-calls. It is de- 
scribed and illustrated in Section 5.2.2.3 



12-4 Routines 



12.2 General-Routine-Calls 



A routine whose address is computed during execution can be called with a 
linkage other than the default linkage using a general-routine-call. An exam- 
ple of a general-routine-call is given in the following program fragment: 



EXTERNAL ROUTINE 

Fl: FORTRAN_SUB IMOVALUE , 
F2; FORTRAN-SUB NOVALUE » 
F3; FORTRAN-SUB NOVALUE 5 

BIND 

TABLE = UPLIT(F1 »FZ tF3) : VECTOR? 

♦ ♦ ♦ 

FORTRAN_SUB( .TABLEC . ID » Pit PZ ) 



The address of the FORTRAN routine to be called is computed by fetching an 

element of a vector. Because the routine has linkage-type FORTRAN SUB, 

the general-routine-call must be used to give the compiler the information 
necessary to generate the correct form of routine-call. 

12.2.1 Syntax 



general-routine- 
call 


linkage-name 

( routine-address 

/ ( , input-actual-parameter ,... ) \ 
1 \ nothing J 1 

< J ; output-actual-parameter ,... ) > ) 
j ( nothing J 1 

\ nothing / 


linkage-name 


name 


routine-address 


expression 


input- 
actual-parameter 


( expression ) 
\ nothing ) 


output- 
actual-parameter 


( expression ) 
( nothing ] 
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12.2.2 Restrictions 

For BLISS-16, a linkage-name defined with the linkage-type INTERRUPT or 
RSX AST may not be used in a general-routine-call. 

The evaluation of the routine-address expression must yield the address of 
a routine that is declared with the specified linkage-name as its linkage- 
attribute. 

The number of input-actual-parameters in a routine-call must agree with the 
number of input-formal-parameters in the routine-declaration. (This restric- 
tion can be relaxed through use of the linkage-functions described in Section 
13.6.) 

The value of each input-actual-parameter must be consistent with the context 
in which the corresponding input-formal-parameter is used in the routine- 
declaration. 

An output-actual-parameter may be any expression, including an undotted 
register-name qualified by position, size, and sign-extension information (i.e. 
field-reference). 

The number of output-actual-parameters must be less than or equal to the 
number of output-formal-parameters specified in the routine declaration. 

An output-actual-parameter must not be specified if a corresponding output- 
parameter-location register is not specified in the linkage. 

The order in which the routine-address expression and actual-parameters are 
evaluated is as follows: Input-actual-parameters are evaluated prior to the 
routine call, and output-actual-parameters are evaluated when the routine 
returns to the caller. 



12.2.3 Semantics 

In a general-routine-call, the routine-address expression is interpreted as the 
address of the routine to be called and the remaining expressions are inter- 
preted as the actual parameters of the call. The linkage to be used is given by 
the linkage-name. In all other respects, the semantics is the same as for an 
ordinary-routine-call. 



12.3 Routine-Declarations 



A routine-name can be declared in five different ways in BLISS. An ordinary - 
routine-declaration is used to give the definition of a routine that is used only 
in the block in which it is declared. A g/ofra/-routine-declaration is used to 
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give the definition of a routine that is used in other modules as well as in the 
module in which it is declared. A /ora>ard-routine-declaration declares the 
name of a routine so that it can be called from a point in the block that 
precedes its complete definition, which is given by an ordinary- or global- 
routine-declaration. An e;c£eraa/-routine-declaration declares the name of a 
routine whose definition is given as a global-routine-declaration in another 
module. A 6md-routine-declaration gives the definition of the address of a 
routine in terms of an expression. 

The first four ways of declaring a routine-name are described in the following 
sections. The bind-routine-declaration is described in Section 14.4. 

12.3.1 Syntax 





/ ordinary-routine-declaration \ 


routine-declaration 


1 global-routine-declaration I 




| forward-routine-declaration f 




\ external-routine-declaration / 



12.3.2 Semantics 

The semantics of the routine -declaration is given in the following sections 
where each kind of routine-declaration is considered separately. 

1 2.4 Ordinary-Routine-Declarations 

An ordinary-routine-declaration defines a routine. The scope of the declared 
routine-name is the immediately containing block (including all contained 
blocks). The declaration includes an expression, the routine -body, which is 
evaluated each time the routine is called. The declaration also includes a list 
of formal-names. When the routine is called, the value of each actual-parame- 
ter in the routine-call is assigned to the corresponding formal-name. The 
formal-names can be accessed in the routine-body as if they were LOCAL 
data segment names, except that values must not be assigned to them. 

A BLISS routine can be recursive. A routine is recursive if it can be called 
while a previous call is still active. Recursion can be direct or indirect. Direct 
recursion occurs when the routine contains a call on itself; for example, the 
routine-body for the routine A contains a call on the routine A. Indirect 
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recursion occurs when the routine contains a call on another routine, which 
ultimately results in a call on the routine being declared; for example, the 
routine-body for the routine A contains a call on the routine B, which contains 
a call on the routine A. 

An example of an ordinary-routine-declaration is: 

ROUTINE AVERAGE3(F1 »F2#F3) = (,F1 + . F2 + .F3)/35 

The routine AVERAGE3 has three formal-names Fl, F2, and F3. An example 
of a call on this routine is: 

AVERAGE3<5» .A, • B* . C ) 

Another example of an ordinary -routine-declaration is the declaration of 
a factorial routine. This routine computes the mathematical function 
factorial(n): 

ROUTINE IFACT (N) = 
BEGIN 
LOCAL 

RESULT 5 
RESULT = 1 5 
INCR I FROM 2 TO ,N DO 

RESULT = .RESULT*. I i 
.RESULT 

end; 

When the routine IFACT is called it computes the factorial of the actual- 
parameter specified. Observe that if the content of N is less than 2, the 
indexed-loop is not executed and the value of the routine is 1. An example of a 
call in this routine is: 

IFACT( ,A * .B) 

In this example, if the content of A is assumed to be 2 and the content of B is 
assumed to be 3, the result returned by the call is 720. 

The factorial routine could be rewritten as a directly recursive routine, as 
follows: 

ROUTINE RFACT (N) = 
IF .N GTR 1 
THEN 

.N * RFACT ( .N - 1 ) 
ELSE 

1 i 

(For the computation of a factorial the first version, IFACT, is more efficient 
than the recursive version, RFACT. Recursion is used when it is the most 
natural and/or efficient method.) 



12-8 Routines 



12.4.1 Syntax 



ordinary-routine- 
declaration 


ROUTINE routine-definition ,... ; 


routine-definition 


routine-name 

/ ( input-list ) \ 
1 ( ; output- list ) ( 
| ( input -list ; output -list ) 1 
V nothing ' 

J : routine-attribute ... ) 
\ nothing ) 

■■=-- routine-body 


routine-name 


name 


input-list 


input-formal-parameter , . . . 


output-list 


output -formal-parameter ,... 


input- \ 
formal-parameter 1 

output- | 
formal-parameter / 


formal -item 


formal -item 


formal-name [ : formal-attribute-list ) 
( nothing j 


formal-name 


name 


formal- 
attribute-list 


j map-declaration-attribute... j 


map-declaration- 
attribute 


/ allocation-unit \ <= 16/32 Only 
1 extension-attribute I <= 16/32 Only 
\ structure-attribute / 
1 field-attribute 1 
V volatile-attribute / 


routine-attribute 


/ novalue-attribute \ 

l linkage-attribute 1 

I psect-allocation \ 

1 addressing-mode-attribute 1 <= 16/32 Only 

V weak-attribute ' o 32 Only 


routine-body 


expression 
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12.4.2 Restrictions 

The number of input-formal-parameters in the routine-declaration must agree 
with the number of input-actual-parameters in the routine-call. (This restric- 
tion can be relaxed through use of the linkage-functions described in Section 
13.6.) 

The number of output-formal-parameters in the routine-declaration must be 
less than or equal to the number of output-parameter-locations specified in 
the linkage-declaration. 

An output-formal-parameter must not be specified if a corresponding output- 
parameter-location is not specified in the linkage. 

The value of an output-formal-parameter is undefined until it is assigned a 
value within the routine-body. 

An input-formal-name must not be assigned a value. 

Both the value of a formal-name and its content are undefined except during 
the evaluation of the routine-body. 

If the routine is declared with the NOVALUE attribute, it must not be called 
in a context that requires a value and if any RETURN expression in the 
routine-body has a returned-value, the expression is evaluated but its value is 
not used. If the routine does not have the NOVALUE attribute, any RETURN 
expression in the routine-body as well as the routine-body itself must have a 
returned-value. 

Suppose the routine-body of a given routine, routine A, contains the declara- 
tion of another routine, routine B. If a name is a formal-name for routine A, 
then that name cannot be used as such within routine B. Such usage would be 
an "up-level" reference, which is prohibited for formal-names just as for local- 
names (see Section 10.5). 

12.4.3 Defaults 

Each formal-name is implicitly declared by a routine-declaration. Each decla- 
ration is assumed to be a scalar, with a default allocation-unit and extension- 
attribute (BLISS-16/32 only). If this assumption is not appropriate, other 
map-declaration-attributes can be specified (see Section 12.4.5.3). 

If a linkage-attribute is not given and the routine is in the scope of a LINK- 
AGE switch, then the default linkage-attribute is the linkage-name given by 
the LINKAGE switch (see Section 18.2 and 19.2). Otherwise, the default is 
the predeclared linkage-name BLISS for BLISS-16/32, or BLISS36C for 
BLISS-36. 



12.4.4 Semantics 

The compiler makes use of the information in an ordinary-routine-declaration 
as follows: 

1. The attributes and keywords are processed. 
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2. The routine-body is processed. Input- and output-formal-names are 
treated as LOCAL variable names that are declared in an implicit block 
enclosing the routine-body. The input-formal-names are then initial- 
ized with the values of the corresponding input-actual-parameters from 
a routine-call; however, output-formal-names are not initialized with 
corresponding output-actual values. 

3. When the routine returns to the caller, the contents of the data-segment 
associated with each autput-formal-parameter, are moved to the regis- 
ters specified in the associated linkage-declaration. 

4. If the routine is declared with the NOVALUE attribute, the mechanism 
for returning a value is suppressed. 

12.4.5 Pragmatics 

The following sections give examples that illustrate various aspects of the 
routine facility of BLISS. 

12.4.5.1 Parameter Passing — The value of each actual-parameter of a rou- 
tine-call is passed to the routine by means of the corresponding formal-name. 
However, the value of the formal-name is not the value of the actual-parame- 
ter. Instead, each formal-name designates a data segment that contains the 
value of the actual parameter. The data segment designated by the formal- 
name is defined only during evaluation of the routine-body, and it is "tempo- 
rary" in that sense. 

Since it is the value of an actual-parameter that is normally of interest (rather 
than the address of the temporary data segment that contains that value), a 
use of a formal-name without a preceding fetch-operator is often an error. 

For example, consider the following routine-declaration: 

ROUTINE AVERAGE3(F1 fFZ»F3) = 
( .Fl + .F2 + .F3>/35 

This routine is called with three actual-parameters whose values are to be 
averaged. An example of a call on the routine is: 

AVERAGE3(5» . A> . B*.C) 

Each formal-name of the routine can be thought of as a special kind of 
LOCAL name that is declared in the implicit block that surrounds the rou- 
tine-body. Therefore, the routine-body for AVERAGE3 can be thought of as 
the following block: 



BEG] 


:n 






LOCAL 








Fl * 








F2 t 








F3 5 






Fl = 


= 55 






F2 = 


= .a; 






F3 = 


■■ .B* 


♦ C ! 


! 


( .Fl 


. + . 


F2 


+ 


END 









F3) /3 
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This interpretation shows that it is .Fl, .F2, and .F3 that represent the values 
to be averaged, not Fl, F2, and F3. 

In the preceding example, the routine-call supplied values that were intended 
for calculation. It is also possible for a routine-call to supply values that are 
intended for use as addresses. For example, consider the following routine- 
declaration: 

ROUTINE EXCHANGE ( X >Y) : NO VALUE = 
BEGIN 

LOCAL temp; 
TEMP = ,,X! 
. X = . ♦ Y ; 

.y = .temp; 
end; 

This routine is called with two actual-parameters whose values are the 
addresses of data segments. An example of a call on the routine is: 

EXCHANGE (Q »R> 

When this call is evaluated, the contents of Q and R are interchanged. Once 
again, each formal-name can be thought of as a special kind of LOCAL name. 
Thus the given parameters Q and R are represented by .X and .Y, respec- 
tively, not by X and Y. 

Note that routines coded to be called from FORTRAN must assume that 
actual-parameter values are always the addresses of data segments. This is so 
because FORTRAN routines pass parameters by address, not by value. 

As an example, consider the following modification of AVERAGE3: 

ROUTINE AVERAGE3A(F1 »F2 »F3) = 
< . .Fl + ,,FZ + . .F3)/3; 

This routine requires that the actual-parameters be the addresses of the val- 
ues to be averaged. Thus a BLISS call on this routine might be: 

AVERAGE3A(UPLIT(5) i At XREF < . B* . C ) > 

This call on AVERAGE3A gives the same value as the call, given earlier, on 
AVERAGE3. The first actual-parameter uses a UPLIT (see Section 4.4) to 
supply the address of the numeric-literal 5. The second actual-parameter 
simply uses the name A (without a fetch operator) to get the address of the 
value. The third actual-parameter uses the %REF standard function (see 
Section 5.2.) to supply an address for the value of the expression .B*.C. 

The routine AVERAGE3A uses addresses of values where values would have 
been sufficient for, e.g., interaction with other BLISS routines. That is to say, 
it does not minimize indirection. However, the routine is valid and, coded in 
this way, can be made callable from programs written in the FORTRAN 

language by the addition of the FORTRAN FUNC linkage-attribute (see 

Section 13.5). 
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12.4.5.2 Allocation of Formal-Name Data Segments — While data segments 
for formal-names are like local data segments in most respects (as discussed in 
Section 12.4.5.1), they are not necessarily allocated in the same way as local 
data segments. Formal data segments are allocated and assigned values by 
the routine making a call, rather than by the routine that is called. The 
calling routine may arrange to allocate formals in static memory that is pro- 
tected from write access rather than, for example, in a temporary segment in a 
stack frame. This is an optimization because, under suitable conditions, the 
calling routine does not need to allocate and assign values for the formals each 
time the call is made. Moreover, the calling routine may even be able to use 
the same formal data segments for different routine calls if they have the 
same number and sequence of actual parameter values. A restriction given in 
Section 12.4.2, namely, that a formal name must not be assigned a value, 
assures that it is valid for a calling routine to use such optimizations. 

12.4.5.3 Attributes for Formal-Names — If the default attributes 
(UNSIGNED WORD in BLISS-16, UNSIGNED LONG in BLISS-32, none in 
BLISS-36) are not appropriate for a formal-name, an appropriate attribute 
can be selected from the map-declaration-attributes. An example of the use of 
a structure-attribute in an ordinary routine declaration is: 

REF BITUECT0RE12] *B »C) : NOYALUE = 



ROUTINE 


ZEROBIT(A 


BEGIN 




IF , 


» AC .B] 




THEN 






BEGIN 






AC ,B] 


= o ; 




.C = . 


♦ c + 




end; 




END' 


5 





The structure-attribute REF BITVECTOR[12] is provided for the first formal- 
name, A. Assuming the content of B is i, the routine ZEROBIT tests the i'th 
bit of the bitvector structure A. If that bit is 1, it is set to and the content of 
the location pointed to by .C is incremented. 

12.4.5.4 Computed Routine Addresses — A routine-call usually begins with a 
routine-name, which designates the routine in an explicit and constant way. 
However, a routine-call can begin with any expression that yields a valid 
routine address. As the basis for an example, consider the following sketch of a 
routine-declaration: 

ROUTINE EIMTVALCA »ERR) : NOVALUE = 
BEGIN 

, . ♦ (Try to enter .A in L I ST 1 ) 
IF ♦FILLED THEN <.ERR)(1> .A)? 
... (Try to enter .A in LISTS) 

if .filled then ( . err ) ( 2 » ,a)5 
end; 
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The details are omitted, but assume that this routine tries to put the content 
of A into two lists, LIST1 and LIST2. If the list is filled up, an error message 
must be printed. However, ENTVAL does not print a message and does not 
even call a specific routine to print an error message. Instead, ENTVAL calls 
a routine whose address is given as one of the formal-names. 

An example of the use of ENTVAL is: 

ROUTINE ERRX(NA'AL): NOVALUE = 
BEGIN 

. . 4 (Print error message for invalid . X ) 
END 



ENTVAL ( .X »ERRX) 

In this example, ENTVAL is called in order to enter the contents of X in the 
lists. The second parameter of the call is ERRX, which is the name of a 
routine designed especially to report an invalid value of .X. Observe that the 
name ERRX in this call does not call the routine ERRX because there are no 
parentheses following it. Thus, ERRX is not a routine call. Presumably, the 
same program contains other calls on ENTVAL, and different calls use differ- 
ent routines to report an invalid value. 

12.5 Global-Routine-Declarations 

A global-routine-declaration provides the same information as the ordinary- 
routine-declaration. The only difference between these two declarations is 
their scope. A routine that is declared in an ordinary-routine-declaration can 
only be called in the block in which the declaration is given (Section 8.2.4). A 
routine that is declared in a global-routine-declaration can be called outside 
the block in which it is declared. The scope of the routine-name is extended 
beyond the block by means of one or more external-routine-declarations in 
other blocks or modules. 

The only differences between the syntax of the ordinary-routine- declaration 
and the global-routine-declaration are that the GLOBAL keyword is required 
in the latter and, in BLISS-32 only, the weak-attribute is permitted in a 
global-routine-declaration. 
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12.5.1 Syntax 



global-routine- 
declaration 


GLOBAL ROUTINE global-routine-definition ,... ; 


global-routine- 
definition 


routine-name 
// ( input-formal-parameter ,... ) \ 
1 ( nothing } 1 

/ ( ; output-formal-parameter ,... ) J 
V \ nothing J ) 

( : global-routine-attribute ... ) 
( nothing ) 

= routine-body 


routine-name 


name 


global-routine- 
attribute 


/ novalue-attribute \ 

l linkage-attribute I 

< psect-allocation / 

I addressing-mode-attribute 1 <= 16/32 Only 

\ weak-attribute ' <= 32 Only 


routine-body 


expression 



12.5.2 Restrictions 

The restrictions given in Section 12.4.2 for ordinary-routine-declarations also 
apply to global-routine-declarations. 

BLISS-16 and BLISS-36 restrictions on names declared as global are given in 
Section 4.5.2. 



12.5.3 Defaults 

The defaults given in Section 12.4.3 for ordinary-routine-declarations also 
apply to global-routine-declarations. 



April 1983 



Routines 



12-15 



12.5.4 Semantics 

The compiler makes use of the information in a global-routine-declaration as 
follows: 

1. The global nature of the routine is recorded. An indicator is set for the 
linker to show that this is a global-declaration. If the routine-declara- 
tion has the weak-attribute, another indicator is set for the linker. 

2. The semantics are then the same as the semantics for an ordinary- 
routine-declaration, given in Section 12.4.4. 

1 2.6 Forward-Routine-Declarations 

Every routine must be declared by an ordinary- or global-routine declaration. 
Sometimes, however, it is necessary to use the routine-name before its full 
definition is given. Prior to such a "forward" use of the name, a forward- 
routine-declaration must be used to declare the name as a routine-name and 
to associate a limited set of attributes with it. 

As an example of the use of a forward-routine-declaration, consider the two 
routines A and B. The routine A calls the routine B and the routine B calls the 
routine A. If the ordinary-routine-declaration for A is given first, a forward- 
routine-declaration must be given for B. If the ordinary routine-declaration 
for B is given first, a forward-routine-declaration must be given for A. 

In general, the use of a forward-routine declaration (at the beginning of a 
block) to specify all of the routine-names that are declared in the remainder of 
the block serves as a useful "table of contents" and allows the routines to be 
written in an order that is independent of their caller/callee relationships. 

12.6.1 Syntax 



forward-routine- 
declaration 

forward-routine- 
item 


FORWARD ROUTINE forward-routine-item ,... ; 

routine-name i : fwd-routine-attribute ... ) 
( nothing ) 


fwd-routine- 
attribute 


/ novalue-attribute \ 
1 linkage-attribute 1 
1 psect-allocation i 
\ addressing-mode-attribute ) <= 16/32 Only 


routine-name 


name 
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12.6.2 Restrictions 

A routine-name declared in a 'forward-routine-declaration must appear in an 
ordinary- or global-routine-declaration later in the same block. 

After any default attributes are filled in, a forward-routine-declaration must 
agree with its corresponding ordinary- or global-routine- declaration with re- 
spect to the set of attributes allowed in both declarations. 

12.6.3 Semantics 

A forward-routine-declaration declares a name to be a routine-name whose 
definition is given later in the same block, and associates with that name the 
set of attributes needed for generation of calls to the named routine. The 
semantics of the BLISS 32 addressing-mode-attribute (which is not one of the 
ordinary or global routine-attributes) is described in Section 9.13. 

1 2.7 External-Routine-Declarations 

Often a routine must be defined in one block of a program and called in other 
blocks of the same program. Usually this situation arises from the organiza- 
tion of the program into separately compiled modules, but this need not be 
the case. 

In order to provide for the linkage between routine-calls and routine defini- 
tions that occur in different scopes (e.g., different modules), external-routine- 
declarations must be used. Specifically, the routine-name is declared in one 
block by a global-declaration (which defines the routine) and is declared in 
the other blocks by external-declarations. 

12.7.1 Syntax 



external- 
routine- 
declaration 



EXTERNAL ROUTINE external-routine-item ,. 



external- 
routine-item 



routine-name 



: ext-routine-attribute 
nothing 



routine-name 



name 



ext-routine- 
attribute 



novalue-attribute 

linkage-attribute 

psect-allocation 

addressing-mode-attribute 

weak-attribute 



<= 16/32 Only 
<= 32 Only 
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12.7.2 Restrictions 

A name must not be declared EXTERNAL ROUTINE unless it is declared 
GLOBAL ROUTINE or GLOBAL BIND ROUTINE in some other block of 
the same program. This restriction does not apply, however, to an EXTER- 
NAL name that is declared with the weak-attribute (BLISS-32 only; see 
Section 9.14). 

12.7.3 Semantics 

An external-routine-declaration informs the compiler that the definition of 
the routine-name is not in the current block. The compiler takes note of the 
attributes given in the external-routine-declaration. Then, each time a use of 
the declared routine-name is encountered, the compiler leaves a blank space 
in the object code for the routine-address. Later, the linker fills in the blank 
with a specific address. 

The attributes in an external-routine-declaration provides the information the 
compiler and linker need to proceed in the absence of a full routine-declara- 
tion in the same module. The linkage attribute gives the compiler information 
about the type of call to generate for the routine and the availability and uses 
of registers within the routine. In particular, the novalue-attribute permits the 
compiler to detect an invalid call on the routine (a call that expects a value). 
The addressing-mode-attribute and weak-attribute (BLISS-32 only) are de- 
scribed in Chapter 9. 
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Chapter 13 
Linkages 



A linkage is the particular calling-sequence convention used in calling a rou- 
tine, and thq register-management discipline used during execution of the 
routine that is called. The type of object code generated by the compiler for a 
routine-call is determined by the linkage-definition associated with the called 
routine. The linkage-definition also controls the object code generated for the 
entry and exit sequences of the routine with which it is associated. Thus, a 
linkage serves as the bridge between a routine and any routines that call it. 

A linkage-definition may be explicitly declared in a linkage-declaration. Each 
BLISS dialect also provides several predefined linkages: one designed for 
standardized calls between BLISS-compiled routines (used as the default 
linkage), and others for calls between BLISS-compiled routines and FOR- 
TRAN-compiled routines. In the case of BLISS-36, a predefined linkage is 
also provided for compatibility with BLISS-10. 

Each linkage-definition, whether predefined or explicitly declared, is identi- 
fied by a linkage-name. Every routine, in turn, has a linkage-name associated 
with it, either by default or by explicit specification of a linkage-attribute in 
the routine's declaration. 

The BLISS linkage facility consists of the following features: 

• Linkage-declarations 

• Predeclared linkage-names 

• Linkage-functions (a class of executable-functions) 

• Global-register-declarations 

• External-register-declarations 

This chapter describes the first three language features, and then discusses 
their use in conjunction with the global- and external-register-declarations. 
Primary descriptions of the register declarations are given in Chapter 10. 

In general, the BLISS linkage facility provides a type of control over the 
compiled code that is quite unusual in high-level languages, but which is often 
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needed for efficiency-sensitive system applications. It allows, when necessary, 
a high degree of control over the kind of calling sequence generated by the 
compiler, and the register-usage conventions that are observed by related 
routines. This control might be exercised, for example, in order to optimize a 
given routine or group of routines (e.g., a subsystem) in terms of either size or 
execution time, or to produce a BLISS routine suitable for use with software 
written in other languages. 

13.1 Introduction to Linkage-Declarations 

A linkage-declaration declares a linkage-name that is defined by a particular 
combination of linkage characteristics. These characteristics include: 

• Linkage-type — The general type of calling sequence, in terms of the 
specific transfer-of-control instructions and/or the software calling con- 
vention. 

• Parameter-location options — The method by which actual-parameters 
are passed. 

• Register-usage options — Specification of the registers that are saved and 
restored across a call, and of those that will not be used in a called 
routine. 

• Global-register options — Specification of register data segments that are 
shared between routines. 

The linkage-declarations of each BLISS dialect are quite system-specific; 
they are tailored to the particular hardware capabilities of each system and to 
the major software calling conventions in use on those systems. Nonetheless, 
there are many aspects of linkage-declarations that apply to two or more of 
the BLISS dialects. 

This introduction to linkage-declarations explains the common aspects in 
three sections. The first discusses the many ways that registers can be used. 
This section is especially important because it establishes much of the vocab- 
ulary and many of the concepts used throughout this chapter. The second 
section presents a partial syntax for linkage-declarations that includes con- 
structs common to at least two of the BLISS dialects. The third section 
describes the parts of the linkage-declaration and further develops the con- 
cepts introduced in the first section. 

13.1.1 Register Usage 

During the execution of a routine, some temporary storage is usually needed 
for holding values until they are used. The stack frame associated with the 
execution of the routine is one place to hold such values and the general 
registers are another. The general registers are more often preferable to the 
stack frame because they can be accessed more quickly and/or with shorter 
instructions. However, when one routine calls another, some consistent rules 
regarding register usage must be observed in order for both to use the machine 
registers correctly. 
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The different uses of these registers can be broadly classified as special pur- 
pose and general purpose. Special purpose registers are dedicated for the same 
particular purpose among a group of routines; frequently that group is all of 
the routines of a program. General purpose registers are used for a variety of 
purposes by different routines and even within a single routine. This classifi- 
cation is hardly precise and does not even consider certain other kinds of 
usage that are described later; but it does provide a basis for discussion. 

13.1.1.1 Special Purposes — In BLISS there are five types of special pur- 
poses to consider for register usage: program counter, stack pointer, frame 
pointer, argument pointer, and value-return register. (As will be seen, regis- 
ters are not dedicated for all of these purposes in every routine.) 

The program counter register is used to contain the address of the next in- 
struction to be executed. In BLISS-16, the program counter is always register 
7 and in BLISS-32 it is always register 15. In BLISS-36, the program counter 
is a special, not generally accessible part of the machine architecture, and 
thus does not figure in BLISS-36 register assignments. 

The stack pointer register is used to contain the address of a portion of mem- 
ory used for temporary storage during the execution of each routine. When a 
routine is called, the stack pointer is adjusted to point to a new area and when 
the routine returns the previous address is put back. The stack pointer may be 
adjusted many times during the execution of the routine as the need for 
temporary storage grows and diminishes in different parts of the routine. The 
portion of storage between the original address in the stack pointer and the 
current value at any particular point in time is known as the stack frame for 
that call of the routine. 

Stack frames can vary greatly in size and complexity. A stack frame might be 
as small as a single fullword containing the program counter for returning to 
the calling routine or it might be very large, containing many values, fields, 
addresses, preserved register values, and so on. 

The frame pointer register is used to contain the address of a fixed part of the 
stack frame of a routine. In contrast with the stack pointer, which may be 
adjusted many times during the execution of a routine, the frame pointer is 
generally set once at the beginning of routine execution and only changes 
when another routine is called and when the routine completes and returns. 
The utility of a frame pointer comes from this "stable" characteristic; the 
frame pointer makes access to fixed parts of the stack frame simple and 
efficient. 

The argument pointer register is used to contain the address of a block of 
storage that contains the values of the actual-parameters of a routine-call. 

The value return register is a register used to contain the value of a routine 
during the process of completion and returning. 

The value return register, unlike the other special registers, is used as such 
only briefly during the completion of one routine and the resumption of the 
calling routine. Consequently, this register can also be used for general pur- 
poses during the execution of a routine. 
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13.1.1.2 General Purposes — A register that is not dedicated to one of the 
special purposes described in the preceding section can be used in a variety of 
ways. These uses are divided as follows: 

Locally usable 

Preserved 

Non-preserved 
Globally usable 
Not used 

A preserved register contains the same value after returning from a routine- 
call as it contained at the time the routine was called. 

A non-preserved register does not (necessarily) contain the same value after 
returning from a routine-call as it contained at the time the routine was 
called. 

Preserved and non-preserved registers are together called locally usable regis- 
ters. This combined designation is convenient because many of the rules 
concerning register usage apply equally to both preserved and non-preserved 
registers. 

Locally usable registers are used by the compiler according to its optimization 
strategies. The compiler determines how many of them to use, which to use 
for evaluating expressions, which to allocate for local data segments, and 
so on. 

A globally usable register is used to contain a global register data segment, 
that is, a register data segment that is accessible in more than one routine. 
Global register data segments are governed by special rules involving LINK- 
AGE declarations in combination with GLOBAL REGISTER and EXTER- 
NAL REGISTER declarations. See Section 13.7 for complete details. 

A not used register is simply not used in any way (applicable to BLISS-32 
only). 

13.1.1.3 Other Purposes — Registers can also be used to pass the values of 
actual-parameters of a routine-call to the routine that is called. (These regis- 
ters must be among the locally usable registers of the called routine.) When 
such an actual-parameter is evaluated, the value is assigned to a given regis- 
ter instead of to a position in an argument block or the stack. The routine that 
is called can efficiently fetch such a parameter value because it is already 
available in a register at the beginning of the routine execution. 

One or more of the locally usable registers can be allocated for a data segment 
established by a REGISTER declaration (see Section 10.7). 

13.1.1.4 Multiple Purposes — Most registers are not limited to a single pur- 
pose or class of purpose. The program counter and stack pointer in both 
BLISS-16 and BLISS-32, as well as the frame pointer in BLISS-32, are truly 
dedicated by the hardware for these purposes; but these are the only cases. 

Registers can be used for multiple purposes so long as those uses do not 
conflict. Because of the many different kinds of use, the rules for compatible 
use are complicated and lengthy. Even so, BLISS still does not always allow 
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every imaginable combination; that would get even more complicated and 
lengthy. But, by and large, BLISS does allow nearly all of the register uses 
and combinations of uses that play a significant role in system software on 
each of the target systems. 

13.1.2 Typical Syntax 



linkage-declaration 


LINKAGE linkage-definition ,... ; 


linkage-definition 


linkage-name = linkage-type 

/ / ( input-parameter-location ,... ) \ 
1 ( nothing J J 

\ ( ; output-parameter-location ,... ) \ / 
/ ( nothing J 1 
\ nothing / 

( : linkage-option ... ) 
\ nothing J 


linkage-type 


( CALL ) 


input-parameter- 
location 


( REGISTER = register-number) 
1 STANDARD > 
( nothing / 


output-parameter- 
location 


{ REGISTER = register-number } 


linkage-option 


/ GLOBAL ( global-register-segment ,... ) \ 
1 {PRESERVE } I 
1 {NOPRESERVE } (register-number ,... ) 1 


global-register- 
segment 


global-register-name = register-number 


global- \ 

register-name > 

linkage-name J 


name 


register-number 


compile-time-constant-expression 



The notation " " in the above diagram indicates that there are additional 

alternatives in some of the dialects that are not shown. 
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This syntax diagram does not apply completely to all of the BLISS dialects, 
but it is representative, (e.g. The CALL linkage-type is part of BLISS-16 and 
BLISS-32, but not BLISS-36.) 

13.1.3 Restrictions 

In BLISS-16, the CALL linkage type is valid with input-parameter-locations, 
but not with output-parameter-locations. 

The general-registers referenced by output-parameter-locations are implicitly 
NOPRESERVE, and cannot appear in NOTUSED, PRESERVE, or 
GLOBAL linkage modifiers; however, they may appear in NOPRESERVE 
modifiers, but this is not required. 

A register-number value must not be given as both a parameter-location and a 
global-register-segment, and must not be given in more than one parameter- 
location or global-register-segment. 

A register-number value must not be given in more than one linkage option. 

13.1.4 Semantics 

The same register may be both an input- and an output-parameter-location. 

Each output-parameter-location specifies that a result from the evaluation of 
the routine-body will be returned in that register. 

The output-actual expressions in the routine-call are associated with the out- 
put-parameter-location registers specified by the linkage-declaration. When 
the routine returns to the caller, the contents of each output-parameter-loca- 
tion register is assigned to the output-actual field reference. 

If fewer output-actual expressions are present than were specified by the 
linkage, the remaining output-parameter-location registers are treated as 
NOPRESERVE's. If an empty element (identified by a null expression) ap- 
pears in the list, it will (when output-actuals are bound to the appropriate 
output-parameter-location registers) be treated as a "place holder". 

The linkage-declaration defines a name for a particular combination of calling 
sequence characteristics. A name so declared can be used as a linkage-attrib- 
ute in any kind of routine-declaration. The several parts of a linkage-defini- 
tion are described in the following sections. 

13.1.4.1 Linkage-Types — The linkage-type selects the principal characteris- 
tics of the calling sequence to be used. Each linkage-type generally establishes 
the following: 

• The specific machine instructions to be used to transfer control to a 
routine and to return from the routine. 

• Whether or not an argument pointer is used to address actual-parameter 
values. 

• Which linkage-options are applicable. 

• The defaults for linkage-options. 
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The CALL keyword occurs as a linkage-type in BLISS-16 and BLISS-32; 
however, the only common characteristic that CALL implies is the use of an 
argument pointer to access actual-parameters (i.e., input- and output-actuals 
for BLISS-32, and input-actuals only for BLISS-16). CALL is not the only 
linkage-type that implies use of an argument pointer; the F10 linkage-type in 
BLISS-36 also implies use of an argument pointer. 

13.1.4.2 Parameter-Locations — An input-actual-parameter of a routine-call 
can be passed to the called routine in one of two ways: it can be passed in a 
standard, or default, method or it can be assigned to one of the general 
registers; however, an output-actual-parameter must be assigned to one of the 
general registers. 

There are two major variations on the standard method; the linkage -type 
determines which one is used. The two methods are: 

• by argument pointer 

• by implicit stack location 

13.1.4.2.1 Argument Pointer Method — In the argument pointer method, all 
of the input-actual-parameters of the routine-call are assigned to successive 
positions in a block called the argument block. The address of this block is 
passed to the called routine using one of the general registers. A register used 
in this way is called an argument pointer register. The called routine fetches 
an input-actual-parameter value from the argument block, using the argu- 
ment pointer value in combination with an offset determined from the formal- 
name that corresponds to that input-actual-parameter position. 

In addition to the input-actual-parameter values, an argument block can 
contain additional information concerning the parameter values. In each 
BLISS dialect, the argument block contains the number of input-actual-pa- 
rameter values in the block. In BLISS-36 other information may also be 
contained in the argument block. 

An argument block may be located anywhere in storage at the option of the 
compiler. It might be part of the stack frame of the routine containing the 
routine-call or it might be in permanently allocated storage. A restriction 
against assigning to a formal-name assures that an argument block can be 
allocated in storage protected against writing and/or reused in the calling 
routine for other routine-calls. 

13.1.4.2.2 Implicit Stack Location Method — In the implicit stack location 
method, the input-actual-parameters of the routine-call are assigned to suc- 
cessive positions in the stack frame of the routine containing the call. No 
explicit value giving the location of the parameters is passed to the routine 
that is called. The called routine fetches an input-actual-parameter value 
using implicit information about where the value is located in the stack 
frame. 

13.1.4.2.3 Register Parameters — In addition to the standard method of 
passing input-actual-parameter values, some or all of the parameters can be 
passed, by assigning them to specified general registers. This method can be 
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used in combination with the standard method; for example, one parameter 
can be passed in a register, and the others in the standard way. However, all 
output-actual-parameters must be passed by the general-register method. 

The general-registers referenced by output-parameter-locations are implicitly 
NOPRESERVE, and cannot appear in NOTUSED, PRESERVE or GLOBAL 
linkage modifiers. The registers may appear in a NOPRESERVE linkage- 
option, but such specification is unnecessary. 

13.1.5 Linkage-Options 

Linkage-options supplement and modify the basic calling sequence conven- 
tions established by the linkage-type. For example, in BLISS-36 the LINK- 
AGE REGS option can be used in combination with the PUSHJ linkage- 
type to specify the registers to be used as the stack pointer, frame pointer, and 
value-return register, respectively, if the default choices for the PUSHJ link- 
age-type are not suitable. 

In some cases, a particular linkage-option must only be used in combination 

with a specific linkage-type. The LINKAGE REGS option just mentioned is 

an example; it must only be used with the PUSHJ linkage-type in BLISS-36. 

In a few cases, linkage-options can be used with several linkage-types and in 
more than one BLISS dialect. The PRESERVE, NOPRESERVE, and 
GLOBAL linkage-options are examples. They can be used in all dialects with 
at least two different linkage-types. 

In the object code generated for a given routine, each register's use is governed 
by one of three usage conventions, each corresponding to one of the following 
linkage-option keywords: 

PRESERVE A preserved register can be used during the execution of 

the routine, but the original contents at the time of the 
routine call must be restored at the time the routine 
completes and returns. 

NOPRESERVE A non-preserved register can be used during the execu- 
tion of the routine (without restoring its original con- 
tents). 

GLOBAL A globally usable register is used only as determined by 

its corresponding GLOBAL REGISTER and EXTER- 
NAL REGISTER declarations, and by explicit source- 
code references to such a register. 

A register that is given in a PRESERVE linkage-option contains the same 
value after returning from a routine as it contained at the time the routine was 
called. The called routine may or may not use the register. If it does, then 
special action is taken to save the contents of the register (push it onto the 
stack) before the register is used and restore it (pop it from the stack) after- 
ward. If the register is not used, then no special action is needed. In either 
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case, a calling routine is able to leave useful information in a register pre- 
served by the routine being called — the information is still available after the 
call. 

A register that is given in a NOPRESERVE linkage-option does not necessar- 
ily contain the same value after returning from a routine as it contained at the 
time the routine was called. The called routine may or may not use the 
register, but in either case no special action is taken to preserve its contents. A 
calling routine must not leave needed information in a register that is not 
preserved by the routine being called — the information may not be available 
after the call. 

Registers that are given in a GLOBAL linkage-option are used to contain 
global register data segments by both calling and called routines. Globally 
usable registers are not managed by the compiler; they are used only as 
explicitly directed by the source program. In certain special cases, depending 
on the linkage-type and other details, a register given in a GLOBAL linkage- 
option may be treated as a preserved register, rather than as globally usable. 
These cases are described later in the sections for each BLISS dialect. 

Globally usable registers are described fully in Section 13.7 where the 
GLOBAL linkage-option and the related GLOBAL REGISTER and EXTER- 
NAL REGISTER declarations are considered together. 

13.2 BLISS-16 Linkage-Declarations 

The linkage capabilities provided by the linkage-declaration in BLISS-16 are 
the following: 

• The JSR, CALL, EMT, TRAP, IOT, INTERRUPT, and RSX_AST 
linkage-types 

• Standard or register parameter-locations for input-actuals and register 
parameter-locations for output-actuals. 

• Globally used and locally used registers 

• The CLEARSTACK, RTT, and VALUECBIT exit sequence linkage-op- 
tions 

As an example of a linkage-declaration, consider the following: 

LINKAGE 

PAR2REG3 = CALL(STANDARD » REGISTER = 3)1 

The declaration indicates that the CALL linkage-type is to be used and that 
the second input-actual-parameter is to be passed using register 3. The first 
input-actual-parameter and any parameters after the second parameter are to 
be passed in the standard way. 
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13.2.1 Syntax 



linkage-declaration 



LINKAGE linkage-definition ,. 



linkage-definition 



linkage-name = linkage-type 



input-parameter-location , . 
nothing 



(i 



output-parameter-location ,. 



nothing 
nothing 



(: linkage-option ... ) 
nothing J 



16 Only => 



linkage-type 



JSR 

CALL 

EMT 

TRAP 

IOT 

INTERRUPT 

RSX__AST 



input-parameter- 
location 



{ 



REGISTER = register-number 

STANDARD 

nothing 



} 



output-parameter- 
location 



REGISTER = register-number 



16 Only => 



linkage-option 



CLEARSTACK 

RTT 

VALUECBIT 

GLOBAL ( global-register-segment ,... ) 

{ PRESERVE } 

{NOPRESERVE } (register-number ,... ) 



global-register- 
segment 



global-register-name = register-number 



global- 
register-name 
linkage-name 



} 



name 



register-number 



compile-time-constant-expression 



Linkage-type is invalid with output-parameter-locations. 
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13.2.2 Restrictions 

Linkage-names defined with EMT, TRAP, or IOT linkage -types may only be 
used as a linkage-attribute in BIND, GLOBAL BIND, and EXTERNAL 
ROUTINE declarations (or in a general-routine-call as described in Section 
13.2.4.2). 

The register-number value must be in the range to 5. 

A register-number value must not be given as both a parameter-location and a 
global-register-segment, and must not be given in more than one parameter- 
location or global-register-segment. 

A register-number value must not be given in more than one linkage-option. 

If the CALL linkage-type is given, then the register-number of a REGISTER 
parameter-location must be in the range to 4. 

The GLOBAL, PRESERVE, NOPRESERVE, CLEARSTACK, and 
VALUECBIT linkage-options must not be specified with the CALL linkage- 
type. 

If OTS (runtime library) routines are called, register must not be specified 
as a global-register-segment in the calling routine's linkage-definition. 

If the CLEARSTACK linkage -option is given, the number of actual-parame- 
ters in a (general) routine-call must be equal to the number of parameter- 
locations given. 

The VALUECBIT linkage-option may not be specified in a linkage-definition 
for a routine written in BLISS. 

If the VALUECBIT linkage-option is given, the CLEARSTACK linkage-op- 
tion must also be given. 

The RTT linkage-option must only be given with the INTERRUPT linkage- 
type. 

No linkage-option may be given with the RSX AST linkage- type. 

13.2.3 Defaults 

If a parameter-location is not given, then STANDARD is assumed. If a rou- 
tine-call or routine-declaration contains more parameters than are given in 
the associated linkage-definition, then STANDARD is assumed as the param- 
eter-location for each of the additional parameters. 

For the JSR linkage-type, the registers are used as follows, by default: 

Registers Default Usage 

Value return register, non-preserved 

1-5 Preserved 

6 Stack pointer 

7 Program counter 
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For the CALL linkage-type, the registers are used as follows: 

Registers Usage 

Value return register, non-preserved 

1-4 Preserved 

5 Argument pointer 

6 Stack pointer 

7 Program counter 

(The 'default' usage cannot be modified for the CALL linkage-type.) 

For the EMT, TRAP, IOT, INTERRUPT, and RSX__AST linkage-types, the 
registers are used as follows, by default: 

Registers Default Usage 

0-5 Preserved 

6 Stack pointer 

7 Program counter 

13.2.4 Semantics 

A linkage-definition defines a name that designates a particular combination 
of calling sequence options. Generally, such a name may be used as a linkage- 
attribute in any kind of routine-declaration; however, this is not true of all 
linkage-names. 

The linkage-type JSR specifies that the PDP-11 JSR and RTS instructions 
are used by the compiled code, and that the parameters with STANDARD 
parameter-locations are placed on the stack (without a parameter count) and 
accessed by the called routine relative to the stack pointer (SP) register. 

The linkage-type CALL specifies that the PDP-11 JSR and RTS instructions 
are used by the compiled code, and that the parameters with STANDARD 
parameter-locations are passed using register 5 (R5) as the argument pointer. 

The linkage-types INTERRUPT and RSX_AST specify that a routine will 
be "called" only by a PDP-11 hardware or software interrupt. These linkages 
are further described in Sections 13.2.4.1 and 13.2.4.3. 

If REGISTER is specified for a parameter-location, the given register will be 
used as the location to which the actual-parameter value is be assigned, and 
correspondingly, is the location where the called routine expects to find the 
value. This use of a register location to transmit an actual-parameter value to 
a called routine does not affect the semantics associated with the use of the 
corresponding formal-parameter name. 

The CLEARSTACK linkage-option (which may be used only with the JSR, 
EMT, TRAP, IOT, or INTERRUPT linkage-type) specifies that the actual- 
parameters that are placed on the stack for a routine-call are removed from 
the stack by the called routine (instead of by the calling routine). If CLEAR- 
STACK is not specified, they will not be removed by the called routine (and 
are the responsibility of the caller). 
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The VALUECBIT linkage-option (which may be used only with the JSR, 
EMT, TRAP, IOT, or INTERRUPT linkage-type, and only in combination 
with CLEARSTACK) specifies that an external routine declared with this 
linkage-option returns its value in the C bit, and that the value of register is 
undefined on return from such a routine. (This linkage-option is used to 
interface with non-BLISS routines having this value-return characteristic.) 

The RTT linkage-option (which may be used only with the INTERRUPT 
linkage-type) specifies that the PDP-11 RTT intruction should be used to exit 
from the interrupt routine instead of the normal RTI instruction. 

The GLOBAL, PRESERVE, and NOPRESERVE linkage-options specify the 
usage conventions that apply to each PDP-11 machine register at the time a 
routine is called and during the execution of the routine. There are three 
conventions, one corresponding to each of the three linkage-option keywords. 
A usage convention is specified for a register by giving its number in the 
appropriate linkage-option. The description of these linkage-options is given 
in Section 13.1. 

Register usage conventions can be specified only for registers through 5; the 
remaining registers (the stack pointer and program counter) are used only as 
specified in the PDP-11 hardware and software architecture. 

Globally usable registers are not managed by the compiler; they are used only 
as explicitly given in the source program. 

13.2.4.1 INTERRUPT Linkage-Type — A linkage-name defined with the IN- 
TERRUPT linkage-type may only be used as a linkage-attribute in a for- 
ward-, ordinary-, or global-routine declaration. It specifies that the routine to 
which it is applied will only be invoked by a PDP-11 hardware interrupt or 
software simulation of an interrupt (such as an RSX-11 Synchronous System 
Trap). Interrupts may occur as a result of certain 'external' events, such as 
I/O device completion, or as a result of programmed events, such as execution 
of certain instructions: EMT, IOT, and so on. (See Section 13.2.4.3 concern- 
ing the related linkage-type RSX AST.) 

The number of formal-names given for the routine must equal the number of 
values pushed on the stack by the "call". In most cases this is exactly two. 
However, interrupt routines that are called by general-routine-calls using a 
linkage-name defined with a EMT, TRAP, or IOT linkage-type can have more 
than two formal parameters. 

The formal parameters of the routine correspond to the hardware values in the 
order pushed; that is, the first formal parameter corresponds to the first value 
pushed, the second formal parameter corresponds to the second value pushed, 
and so on. Consequently, the last formal parameter corresponds to the pushed 
program counter (PC) and the next to last formal parameter corresponds to 
the pushed processor status (PS). 
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13.2.4.2 EMT, TRAP, and IOT Linkage-Types — In a general-routine-call that 
uses a linkage-name defined with an EMT, TRAP, or IOT linkage-type, the 
following special rules apply: 

• For EMT and TRAP, the first value in the actual-parameter list is no+ 
interpreted as a routine-address. Instead it is interpreted as a value that 
is incorporated into the low byte of the EMT or TRAP instruction itself. 
It must be a compile-time-constant-expression in the range to 255. 

• For IOT, all of the values in the parameter list are actual-parameters. 
There is no routine-address parameter. 

13.2.4.3 RSX_AST Linkage-Type — Similar to the INTERRUPT linkage- 
type, the RSX AST linkage -type specifies that the routine to which it is 

applied will be invoked only by an RSX-11 Asynchronous System Trap 
(AST). The first four formal parameters of such a routine are mandatory and 
correspond to the following context information: (1) the event-flag mask word, 
(2) program-status word, (3) program counter, and (4) Directive Status Word 
of the interrupted task, respectively. Additional formal parameters must be 
specified if the kind of AST that invokes the routine pushes supplemental 
information onto the stack. At the routine's return point, any such supple- 
mental information is removed from the stack and an RSX-11 AST SERVICE 
EXIT directive (rather than an RTS instruction) is executed. 

13.2.5 BLISS-16 Predeclared Linkage-Names 

Four linkage-names are predeclared in every BLISS-16 module. The linkages 
are provided for compatible and transportable usage among the several 
BLISS dialects. See Section 13.5 concerning such usage. 

The predeclared linkage-names are defined as shown in the following declara- 
tion: 

LINKAGE 

BLISS = JSR f 
FORTRAN = CALL » 
FORTRAN_SUB = CALL » 
FORTRAN„FUNC = CALL 5 

13.3 BLISS-32 Linkage-Declarations 

A linkage-declaration in BLISS-32 can be used to specify a CALL, JSB, or 
INTERRUPT linkage-type, to designate registers for passing parameters, and 
to identify registers as globally used, locally used, or not used. As an example 
of a linkage-declaration, consider the following: 

LINKAGE 

DBL-PREC = CALL( 5 REGISTERED , REGISTERED, 

The declaration indicates that the CALL linkage-type is to be used and that 
output-actual-parameters are to be passed using registers and 1 for a dou- 
ble-precision result. Since the registers are treated as output-parameter loca- 
tions the called routine (DBL_PREC) should be declared as NOVALUE. 
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13.3.1 Syntax 



linkage-declaration 


LINKAGE linkage-definition ,... ; 


linkage-definition 


linkage-name = linkage-type 

/ / ( input-parameter-location ,... ) \ 
1 ( nothing J 1 

| ( ; output-parameter-location ,... ) \ i 
1 \ nothing J 1 
V nothing / 

■( : linkage-option ... ) 
( nothing ) 


32 Only => 
linkage-type 


{ CALL 1 JSB 1 INTERRUPT } 


input-parameter- 
location 


( REGISTER - register-number ) 
I STANDARD > 
V nothing / 


output- 
parameter- 
location 


{ REGISTER = register-number } 


32 Only => 
linkage-option 


/ GLOBAL ( GLOBAL-register-segment ,... ) \ 
1 ( PRESERVE ) 1 
1 \ NOPRESERVE> (register-number,...) ( 
V I NOTUSED J / 


global-register- 
segment 


global-register-name = register-number 


global- \ 

register-name > 

linkage-name / 


name 


register-number 


compile-time-constant-expression 



13.3.2 Restrictions 

A NOTUSED linkage-option must only be given with the JSB and INTER- 
RUPT linkage-types. It must not be given in combination with the CALL 
linkage-type. 
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The register-number in a REGISTER parameter-location or a linkage-option 
must be in the range to 11. 

A register-number value must not be given as both a parameter-location and a 
global-register-segment, must not be given as both a parameter-location and 
in a NOTUSED linkage-option, and must not be given in more than one 
parameter-location or global-register-segment. 

A register-number value must not* Joe given in more than one linkage-option. 

Some of the character-handling and machine-specific functions require the 
use of particular machine registers because they result in VAX-11 instruc- 
tions that use specified registers; such functions must not be used if the 
required registers are not locally usable. Observe that at most the set of 
registers through 5 inclusive must be locally usable to satisfy this require- 
ment. 

The VAX-11 calling standard requires that register or registers and 1 
together be used to return routine values. This requirement, combined with 
the preceding general restriction," leads to the following two special case re- 
strictions: 



• 



• 



If a routine-call is in the scope of a global register data segment that is 
allocated in either register or 1, then the routine that is called must not 
return a value; that is, must be declared with the NO VALUE attribute. 

If the linkage-attribute of a routine-declaration specifies registers or 1 as 
PRESERVE, GLOBAL, or NOTUSED, then that routine must also have 
the NOVALUE attribute. 

The VAX-11 calling standard also requires that registers and 1 be usable as 
temporary registers by the condition handling software during processing of a 
signal (see Chapter 17). Further, only routine stack frames associated with the 
CALL linkage-type are used for restoring register contents during unwinding. 
These requirements, together with the above restrictions on linkages, lead to 
the following special case restrictions: 

• A routine-body must not immediately contain an ENABLE declaration if 
the linkage-attribute of the routine is defined with linkage-type JSB, or 
INTERRUPT, or with registers or 1 as either PRESERVE, GLOBAL, or 
NOTUSED. 

• A routine whose linkage -attribute is defined with registers or 1 as PRE- 
SERVE, GLOBAL, or NOTUSED must not be terminated by unwinding. 

• If a routine-call to a routine with JSB linkage-type occurs in a routine 
with JSB linkage-type, all of the locally usable registers of the called 
routine must also be given as locally usable registers of the routine con- 
taining the call. That is, the outermost JSB routine in a nest of JSB 
routines must specify all the registers that are locally usable. (This re- 
striction assures that the CALL routine that calls the outermost JSB 
routine can preserve all the necessary registers.) 

The VAX-11 calling standard is described in Appendix C of the VAX-11/780 
Architecture Handbook, Vol. I. Condition handling, and its interaction with 
linkages, is described in Chapter 17 of this manual. 
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13.3.3 Defaults 

If a parameter-location is not given, then STANDARD is assumed. If a rou- 
tine-call or routine-declaration contains more parameters than are given in 
the associated linkage-definition, then STANDARD is assumed as the param- 
eter-location for each of the additional parameters. 

For the CALL linkage-type, the registers are used as follows, by default: 

Registers Default Usage 

Value return register, non-preserved 

1 Non-preserved 
2-11 Preserved 

12 Argument pointer 

13 Frame pointer 

14 Stack pointer 

15 Program counter 

For the JSB linkage-type, the registers are used as follows, by default: 
Registers Default Usage 

Value return register, non-preserved 

1 Non-preserved 
2-11 Preserved 
12-13 Not used 

14 Stack pointer 

15 Program counter 

Observe that, for both CALL and JSB linkage-types, registers to 11 are 
locally usable by default. 

For the INTERRUPT linkage-type, the registers are used as follows, by de- 
fault: 

Registers Default Usage 

0-13 Preserved 

14 Stack pointer 

15 Program counter 

13.3.4 Semantics 

A linkage-declaration defines a name for a particular combination of calling 
sequence options. A name so declared can be used as a linkage-attribute in 
any kind of routine-declaration. 

The linkage-type CALL specifies that the VAX-11 CALLS/CALLG and RET 
instructions are used. Further, the parameters with STANDARD parameter- 
locations are passed using register 12 (AP) as the argument pointer. 

The linkage-type JSB specifies that the VAX-11 JSB/BSBW/BSBB and RSB 
instructions are used by the compiled code. Further, the parameters with 
STANDARD parameter-locations are placed on the stack (without a count) 
and accessed by the called routine relative to the stack pointer (SP) register. 
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If REGISTER is given as a parameter-location, then the given register is used 
as the location to which the actual-parameter value is assigned in performing 
a routine-call, and correspondingly, is the location where the called routine 
expects to find the actual-parameter value. This use of a register location to 
transmit an actual-parameter value to a called routine does not affect the 
semantics associated with the use of the corresponding formal-parameter 
name. 

The linkage-options specify the usage conventions that apply to each VAX-11 
machine register at the time a routine is called and during the execution of the 
routine. There are four conventions, one corresponding to each of the four 
linkage-option keywords, namely: GLOBAL, PRESERVE, NOPRESERVE, 
and NOTUSED. A usage convention is specified for a register by giving its 
number in the appropriate linkage-option. The description of these linkage- 
options is given in Section 13.1. 

Register usage conventions can be specified only for registers through 11; the 
remaining registers (the argument pointer, frame pointer, stack pointer, and 
program counter) are used only as specified in the VAX-11 hardware and 
software architecture. 

Globally usable registers are not managed by the compiler; they are used only 
as explicitly given in the source program, with the following exception: 

In a routine with a linkage that specifies CALL linkage-type and a globally- 
usable register (in a GLOBAL linkage-option), if the global-register-seg- 
ment is not declared as a global register data segment (using an EXTER- 
NAL REGISTER declaration) within the body of the routine, then the 
compiler can choose to consider the register preserved (and hence, locally 
usable). 

However, in a routine with a linkage that specifies JSB linkage-type, the 
compiler cannot preserve and use such registers. The reason for the difference 
has to do with the requirements for condition handling. Briefly, the CALL 
linkage-type provides the information needed for the condition handling soft- 
ware to properly recover register values when doing unwinding; the JSB link- 
age-type does not. 

Registers that are given in a NOTUSED linkage-option are not used in any 
way. Only routines with a linkage that specifies the JSB linkage-type can 
have registers that are not usable,, 

Some guidelines concerning the choice of registers to specify in a NOTUSED 
linkage-option are discussed in Section 13.7.2. 

13.3.4.1 JSB Linkage-Type — The routine EXCHANGE in Section 12.4.5 is 
an example of a routine that can be made significantly smaller and faster by 
the use of a linkage-declaration such as: 

LINKAGE 

FAST = JSB (REGISTER = 0» REGISTER =1)? 
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When the linkage-attribute FAST is given for the routine EXCHANGE, the 
JSB linkage-type is used instead of the CALL linkage-type and the parame- 
ters are passed in registers and 1. 

When a set of routines with JSB linkage-type call one another, care must be 
taken to ensure that the locally usable registers of the calling routine include 
all the locally usable registers of any routine that it calls. For example, con- 
sider the following linkage-declarations: 

LINKAGE 

JSB„ALL = JSB t 

JSB_N011 = JSB: IMOTUSED ( 1 1 ) 5 

The linkage JSB ALL specifies a JSB linkage-type. Because no linkage- 
options are given, the locally usable registers are registers to 11. The linkage 

JSB NOll also specifies a JSB linkage-type. Because the linkage-option 

indicates that register 11 is not used, the locally usable registers are registers 
to 10. 

Suppose the following routines are declared: 

FORWARD ROUTINE 

ALPHA; JSB„ALL» 
BETA: JSB_N011i 

Then routine ALPHA can legitimately call routine BETA. But routine BETA 
must not call routine ALPHA because the set of locally usable registers of 
ALPHA is not a subset of the locally usable registers of BETA. 

13.3.4.2 INTERRUPT Linkage-Type — The INTERRUPT linkage-type for 
BLISS-32 is used for the same purposes and provides the same functionality 
as that described for BLISS-16, and is similar to the JSB linkage-type. When 
used in a routine-declaration, a linkage-name defined with the INTERRUPT 
linkage-type affects the following: 

• All registers are PRESERVE(d). 

• As necessary, registers are explicitly saved with PUSHL or PUSHR in- 
structions. 

• All references to formal-parameters are via the stack pointer (SP). 

• At routine exit, all but the last two arguments are removed from the 
stack; these are assumed to be a valid program counter (PC) and proces- 
sor status longword (PSL). 

• A Return from Exception or Interrupt (REI) instruction is executed. 

Input- or output-parameter-location REGISTER assignments are not permit- 
ted with INTERRUPT linkages. 

The correct number of formal-parameters must be declared with an INTER- 
RUPT linkage routine to ensure that the compiler cleans the stack on exiting 
the routine; a routine with less than two parameters is invalid. 

An INTERRUPT linkage routine is implicitly declared NOVALUE. 
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An example of an INTERRUPT linkage routine in BLISS-32 follows: 

LINKAGE 

ARITH_EXCP= INTERRUPT: NOTUSED ( 3 »4 »5 »G »7 »B »9 » 10 » 1 1 > 5 

ROUTINE ARITH_EXCP_HDLR(CODE »-PC >PSL) : ARITH_EXCP= 
BEGIN 

CASE .CODE FROM SRM*K_ INT_0VF_T TO SRM$K_FLT_UND_F OF 
SET 



TES 
END 



The code in the example is expanded as follows: 



ARITH_TRAP„HDLR: 
PUSHL RO 

CASEL 4<SP) »*1 »#9 
♦ WORD 



MOOL (SP)+fR0 
ADDL2 #4>SP 



RE I 

Notice in the first line of the expanded code that only one register (RO) is 
needed. In the second line the exception is dispatched via the exception code. 
The register is then restored (MOVL), and the trap code is eliminated 
(ADDL2) before a return (REI) is executed. 

Explicit calls are also permitted to routines declared with interrupt linkage. 
The caller treats such a call as if it was declared with a JSB linkage attribute; 
an exception being that the parameters are automatically removed from the 
stack by the called routine and not the caller. The parameter order is such 
that the caller's PC is always the first formal-parameter and will not appear 
as an actual-parameter in the explicit routine-call. 

If an interrupt linkage routine exists (e.g. SETPSL), that is invoked with only 
the PC and PSL as actual-parameters, the routine can be explicitly called 
with the following BLISS expression: 

SETPSL( ♦NEWPSL ): 

13.3.5 BLISS-32 Predeclared Linkage-Names 

Four linkage-names are predeclared in every BLISS-32 module. These link- 
ages are provided for compatible and transportable usage among the several 
BLISS dialects. See Section 13.5 concerning such usage. 

The predeclared linkage-names are defined as shown in the following declara- 
tion: 

LINKAGE 

BLISS = CALL* 
FORTRAN = CALL » 
FORTRAN„SUB = CALL » 
FORTRAN-FUNC = CALL 5 
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13.4 BLISS-36 Linkage-Declarations 

A linkage-declaration in BLISS-36 can be used to specify a PUSHJ, JSYS, 
F10, or PS__INTERRUPT linkage-type, to identify globally used registers, to 
specify the use of a PORTAL instruction in the entry sequence of a routine, 
and to specify other linkage capabilities. 

As an example of a linkage declaration, consider the following: 



LINKAGE 

PAR2REG4 



PUSHJ (STANDARD » REGISTER 



4) 



The declaration indicates that the PUSHJ linkage-type is used and that the 
second actual-parameter is passed using register 4. The first actual-parameter 
and any parameters after the second parameter are passed in the standard 
way. 

13.4.1 Syntax 



linkage-declaration 



LINKAGE linkage-definition ,... ; 



linkage-definition 



linkage-name = linkage-type 

/ ( input-parameter-location ,... ) 
I nothing J 

(; output-parameter- location ,... ) \ 
nothing J 

nothing 

(: linkage-option ... ) 
nothing J 



36 Only => 
linkage-type 



PUSHJ I JSYS I F10 I PS_INTERRUPT 



input-parameter- 
location 



{ 



REGISTER = register-number 

STANDARD 

nothing 



} 



output- 
parameter- 
location 



REGISTER = register-number 



36 Only => 
linkage-option 



{ 



general-linkage-option 
pushj -linkage-option 
ps_interrupt- linkage-option 



) 
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general-linkage- 
option 


/ GLOBAL ( global-register-segment ,... ) \ 
1 PORTAL 1 
) s PRESERVE \ ( 
\ 1 NOPRESERVE ( , u .( 
1 { SKIP(value) ( (register-number,...)! 

V V CLEARSTACK / / 


pushj-linkage- 
option 


LINKAGE_REGS ( stack-pointer-reg , 
frame-pointer-reg , return-value-reg ) 


ps__interrupt- 
linkage-option 


< PORTAL ) 

\ LINKAGE_REGS ( stack-pointer-reg, S 

V frame-pointer-reg, return-value-reg/ 


stack-pointer-reg J 
frame-pointer-reg > 
return-value-reg / 


register-number 


global-register- 
segment 


global-register-name = register-number 


global- \ 

register-name > 

linkage-name ) 


name 


register-number 


compile-time-constant-expression 


skip-value 


-1 1 1 1 1 2 



13.4.2 Restrictions 

A REGISTER parameter-location (input or output) may only be specified 
with a PUSHJ or JSYS linkage-type. 

Input- and output-parameter-locations may not be specified with a 
PS__INTERRUPT linkage-type. 

The registers referenced by output-parameter-locations are implicitly 
NOPRESERVE and cannot appear in PRESERVE or GLOBAL linkage mod- 
ifiers. 

The register-number in a REGISTER parameter-location must be in the 
range to 15 (JSYS excepted) and must not specify a register given as either 
the stack-pointer-reg or the frame-pointer-reg. (It may be the same as the 
register given as the value-return-reg.). 

The register-numbers for the JSYS linkage must be in the range 1 to 4 (physi- 
cal registers ACl through AC4). 
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The LINKAGE REGS linkage-option may not be given in combination with 

a JSYS or F10 linkage-type. 

NOTE 

The JSYS built-in function is obsolete and should be avoided; 
instead, use the JSYS linkage. 

When using a LINKAGE-REGS option with the PS_INTERRUPT linkage- 
type all three register numbers are required, although the return-value-regis- 
ter is unused. 

The stack-pointer-reg and the value-return-reg in the LINKAGE REGS op- 
tion must be in the range to 15, and the frame-pointer-reg must be in the 
range 1 to 15. The register-number in a linkage-option other than the 

LINKAGE REGS option must be in the range to 15 and must not specify a 

register used as a stack pointer, frame pointer, or argument pointer (if appli- 
cable). 

All of the routines in a given program must use the same stack-pointer regis- 
ter, including any implicitly called OTS routines. (This restriction assures 
that a single object-time-system library can satisfy all of the requirements of a 
program.) 

The same register-number value may not be given as both a parameter-loca- 
tion and a global-register-segment, and may not be given more than once as a 
parameter-location or a linkage-option register-number. There is one excep- 
tion: the register specified as the value return register in a LINKAGE REGS 

option can also be specified as preserved, non-preserved, or global. 

If the value return register is also specified as preserved or global then the 
linkage-name so defined must only be used as a linkage-attribute in the decla- 
ration of a routine that also has the NOVALUE attribute or in a general- 
routine-call in a context that does not require a value. 

The skip-values for the PUSHJ linkage-type are restricted to through 2. 

Some executable-functions impose "hidden" restrictions on the linkage-defi- 
nition and explicit register usage of the containing routine. More specifically, 
some of the character-handling-functions and each of the condition-handling- 
functions result in calls to Object Time System (OTS) routines. 

These implicit routine calls are made with the governing OTS linkage for the 
program (BLISS36C by default). Therefore, any routine containing such func- 
tions must also be able to call a routine having the governing OTS linkage. In 
particular, the containing routine's use of register data segments declared by 
register-number, whether local or global, must be consistent with the register 
conventions of the OTS linkage. (See the restrictions in Sections 10.7, 10.8, 
and 10.9.) 

13.4.3 Defaults 

The defaults for each of the linkage-options depend on the linkage-type that is 
given. 
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Defaults for the PUSHJ Linkage-type: If a parameter-location is not given, 
then STANDARD is assumed. If a routine-call or routine-declaration contains 
more parameters than are given in the associated linkage-definition, then 
STANDARD is assumed as the parameter-location for each of the additional 
parameters. 

Default register usage for the PUSHJ linkage-type is determined in two steps: 

First, the defaults for the LINKAGE REGS option are applied if the 

LINKAGE REGS option is not given; second, the defaults for all remaining 

registers are determined. 

The default for the LINKAGE_REGS option is LINKAGE_REGS(0,2,3), 
that is: 

Register Default Usage 

Stack pointer 

2 Frame pointer 

3 Value return register, non-preserved 

For any register not specified by the explicit or default LINKAGE REGS 

option, the default usage is: 

Registers Default Usage 

0-10 Non-preserved 

11-15 Preserved 

As an example, if the PUSHJ linkage-type is given without any linkage- 
option, then the resulting register usage is the following: 

Registers Usage 

Stack pointer 

1 Non-preserved 

2 Frame pointer 

3 Value return register, non-preserved 
4-10 Non-preserved 

11-15 Preserved 

Defaults for the JSYS linkage-type: For JSYS, the registers are used as 
follows, by default: 

Registers Default Usage 

Preserved 

5-15 Preserved 

1-4 Non-preserved 

Defaults for the F10 linkage-type: For F10, the registers are used as follows, 
by default: 

Registers Default Usage 

Value return register, non-preserved 

1-13 Non-preserved 

14 Argument pointer 

15 Stack pointer 

Observe that a frame pointer is not used. 
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Defaults for the PS_INTERRUPT linkage type: For PS_INTERRUPT, 

the default register usage is determined in two steps: First, the defaults for the 
LINKAGE_REGS option are applied if the LINKAGE_REGS option is not 
given; second, the defaults for all remaining registers are determined. The 
registers are used as follows, by default: 

Registers Default Usage 

Preserved 

1 Value return register, preserved 
2-12 Preserved 

13 Frame pointer 

14 Preserved 

15 Stack Pointer 

Note that the value return register is specified but unused. 

13.4.4 Semantics 

The GLOBAL linkage-option can be used with both PUSHJ and F10 linkage- 
types. It is introduced in Section 13.1 and is discussed in detail in Section 
13.7. 

The PORTAL linkage-option is used with the PUSHJ, F10, and 
PS_INTERRUPT linkage-types. When used in the definition of the linkage- 
attribute of a ROUTINE or GLOBAL ROUTINE declaration, it causes the 
first instruction of the code compiled for the routine to be a PORTAL instruc- 
tion ("JRST 1,.+1"). The PORTAL instruction is used in the construction of 
certain kinds of execute-only programs. See the system hardware manuals for 
details. 

The PRESERVE and NOPRESERVE linkage-options are described in Sec- 
tion 13.1. 

The LINKAGE_REGS option, used only with the PUSHJ and 

PS INTERRUPT linkage-types, specifies the registers to be used for the 

stack pointer, frame pointer, and the value return register. 

13.4.4.1 PUSHJ Linkage-Type — The PUSHJ linkage-type specifies a calling 
sequence in which the actual-parameters are passed on the stack without the 
use of an argument pointer. Unlike the F10 linkage-type, actual-parameters 
can also be passed in registers (as described in 13.1.3.2.3) and the 
LINKAGE — REGS option can be used to specify which registers are used for 
the stack pointer, frame pointer, and value return registers. For example, 
consider the following: 

LINKAGE 

DBL_PREC = PUSHJ( ? REGISTERS, REGISTERS): 
LINKAGE_REGS( 15 ,13 ,1 ) 
N0PRESERUE(2 ,3 tU ,5) 
PRESERVE (0 »G»7»Bi9»10»ll »12 .14) 5 

The example defines linkage for a double-precision result in ACl and AC2, 
with STANDARD locations (i.e., the stack) reserved for an arbitrary number 
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of inputs. Since ACl is treated as an output-parameter-location, the routine 
should be NOVALUE. 

The SKIP linkage modifier determines how the PUSHJ returns to the calling- 
location. The following describes the skip-values used: 

The routine returns to the calling-location plus one (this is the default 
skip- value). 

1 The routine may return to the calling-location plus one or plus two. The 
call value is zero (no skip) or one (skip). 

2 The routine may return to the calling-location plus one, two, or three. 
The call value is then zero, one, or two respectively. 

A non-zero skip-value must only appear in a valued routine, and a value- 
return register must be NOPRESERVE. 

For ROUTINE declarations, the return-value is added to the "saved PC 
value"; therefore, the routine must not be NOVALUE. 

The CLEARSTACK linkage modifier may be used only with PUSHJ. This 
option specifies that the actual-parameters (placed on the stack by a routine- 
call) will be- removed from the stack by the called routine, instead of the 
calling routine. If the modifier is not specified, the parameters will not be 
removed from the stack by the called routine and become the responsibility of 
the caller. Be aware, however, that the number of actual-parameters used in 
the call must be exactly equal to the number of formal-parameters declared. 

13.4.4.2 JSYS Linkage-Type — The JSYS linkage-type specifies a calling 
sequence in which actual-parameters are passed by register to TOPS-20 JSYS 
functions. For example, consider the following: 

LINKAGE 

sin_lnkg = jsys(register=1 » register=2. register=3» 
registers; 
registers » register=zt register=3 ) 

:SKIP( -1 ) ; 
BIND ROUTINE 

SIN = '/.D '52' :SIN_LNKGi 

The SIN routine reads a string from a specified source to the caller's address 
space using an inline JSYS instruction; parameters are passed via AC1-AC4. 

The SKIP linkage modifier determines how the JSYS will return to the call- 
ing-location. The following describes the skip-values used: 

-1 The instruction after the JSYS will be an ERJMP. The value of the 
call is zero if an error occurs, otherwise the value is a one. 

Control is returned to the next instruction; the value of the call is zero. 

1 Control returns to the calling-location plus one or plus two. The value 
of the call is zero (no skip) or one (skip). 

2 Same as 1, except control also can return to the calling-location plus 
three (in which case, the value of the function is two). 
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13.4.4.3 F10 Linkage-Type — The F10 linkage-type specifies a calling se- 
quence in which input-actual-parameters are passed using an argument block 
(see Section 13.1.1.1) whose address is contained in register 14. Register 15 is 
the stack pointer and register is the value return register. 

13.4.4.4 PS_INTERRUPT Linkage-Type — The PS._INTERRUPT linkage- 
type is similar to the PUSHJ and compatible with TOPS-10 and TOPS-20 

software interrupt (PSI) mechanisms; as such, a PS INTERRUPT makes 

use of the DEBRK% JSYS and DEBRK. UUO exit mechanisms for TOPS-20 
and TOPS-10. For example, consider the following: 

LINKAGE 

INTERRUPT = PS_INTERRUPT; 
ROUTINE PSI: INTERRUPT = 

BEGIN 

END; 
Assuming a TOPS-20 compilation, the code expansion would be as follows: 



PSI 



PUSH 



SP» C PSI 36% ] 



"? f a K e return PC to keep 



PUSH 


SP t 


FP 


MOVE 


FP t 


SP 


PUSH 


SP » 




♦ ♦ ♦ 

POP 


SP , 


4 , 


POP 


SP , 


FP 


ADJSP 


SP » 


1 


DEBRKX 







5 5 t a c K 
? COPT] 
5C0PT] 
i C P T 3 save 



adjusted 

set up frame 



necessary AGs 



5C0PT] restore saved AGs 
iCOPT] recover old FP 
5 R e m o v e f a K e r e t u r n P C 
5 R e t u r n to monitor 

Notice that the expansion is exactly like that of a PUSHJ routine; the excep- 
tion being that at routine entry the called routine places a dummy PC on the 
stack, and at routine exit the dummy PC is removed before the DEBRK% 
JSYS is executed. The environment is the same for TOPS-10, the only exe- 
ception being that DEBRK. UUO is used to exit the routine. 

A routine declared as a PS INTERRUPT type must adhere to the following 

rules: 

1. The routine must only be called by the PSI system. 

2. The routine must only fetch from or assign to data segments which satisfy 
one of the following requirements: 

• A data-segment whose scope is limited to the body of the routine 

• A data-segment declared with a VOLATILE attribute 



3. If an UNWIND can occur within the scope of the routine, a condition 
handler must be established via an ENABLE declaration within the rou- 
tine. 

When an UNWIND occurs, it is necessary that a DEBRK% JSYS, or 
DEBRK. UUO be executed to allow subsequent software interrupts to occur. 
To guarantee future interrupts the user must establish a condition handler in 
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the PS_INTERRUPT linked routine. The BLISS-36 OTS uses this handler 
to ensure that the software interrupt system is re-enabled. 

13.4.5 BLISS-36 Predeclared Linkage-Names 

Four linkage-names are predeclared in every BLISS-36 module. These link- 
ages are provided for compatible and transportable usage among the several 
BLISS dialects. See Section 13.5 concerning such usage. The default linkage- 
name is BLISS36C. 
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The predeclared linkage-names are defined as shown in the following declara- 
tion: 

LINKAGE 

BLISS 10 = PUSH J t 
BLISS3SC = 
PUSHJ: 

LINKAGE_REGS( 15,13*1) 
IM0PRESERVE(2 »3 »4 »5) 
PRESERVE (0 t 6»f»8f9»i0»il»12»14)» 
FORTRAN_SUB = FlOt 
FORTRAN-FUNG = 

F10: PRESERVE (2 t3»4»5»6»7 t 8»9»10fll »12 » 13) 5 

The BLISS 10 linkage is provided for convenient interfacing with routines 
compiled by the BLISS-10 compiler. (BLISS-10 is an older dialect of BLISS 
which is becoming obsolete.) The definition of the BLISS 10 linkage given here 
assumes that default register options are used by the BLISS-10 module. 

The BLISS36C linkage is the default linkage for BLISS-36. (The name comes 
from a preliminary bootstrapping version of BLISS-36 that was known as 
BLISS-36C. BLISS-36C is now obsolete.) 

The BLISS36C linkage can also be used for interfacing with BLISS-10 
routines that are compiled using the "/Z" compilation option of the BLISS-10 
compiler. 

13.5 Common Predeclared Linkage-Names 

Two linkage-names are predeclared in all BLISS dialects, namely: FOR- 
TRAN—SUB and FORTRAN_FUNC. In addition, the linkage-names 
BLISS and FORTRAN are predeclared in BLISS-16 and BLISS-32. 

The complete semantics for these linkage-names is given in the earlier sec- 
tions on the linkage-declaration for each dialect (see Section 13.2.5 for 
BLISS-16, Section 13.3.6 for BLISS-32, and Section 13.4.5 for BLISS-36). 
This section summarizes the common characteristics that apply across di- 
alects. 

13.5.1 The BLISS Linkages 

In BLISS-16 and BLISS-32, the BLISS linkage is the default linkage in the 
absence of any other specification. In BLISS-36, the default linkage is 
BLISS36C. The semantics associated with these linkages are given in Sections 
12.4 through 12.7. 

In light of the above, the way to obtain a compatible and transportable BLISS 
linkage in all dialects is to use no explicit linkage specification at all. 

13.5.2 The FORTRAN Linkages 

The FORTRAN-related linkages provide a compatible and transportable 
means to interface with FORTRAN compiled routines on each of the target 
systems. 
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Use of the FORTRAN linkages is quite similar to use of the BLISS linkages 
with these exceptions: 

• Each formal parameter must be assumed to contain a value that is an 
address. The body of the routine must be coded appropriately. (In 
BLISS-32, this restriction can be relaxed through use of the %VAL built- 
in function of VAX-11 FORTRAN IV-PLUS.) 

• Each actual-parameter must be a value that is an address. 

There are several FORTRAN linkages because, in the case of FORTRAN-10 
on the DECsystem-10/-20, FORTRAN-10 compiled SUBROUTINE subpro- 
grams use the machine -registers in a different way than FORTRAN-10 com- 
piled FUNCTION subprograms. (This difference is reflected in the declara- 
tions for the FORTRAN_SUB and FORTRAN_FUNC linkage-names given 
for BLISS-36 in Section 13.4.5.) There is no such difference for PDP-11 and 
VAX-11 FORTRAN systems. 

In light of the above, the way to obtain compatible and transportable interfac- 
ing to FORTRAN with all three BLISS dialects is: 



• 



• 



Use the FORTRAN SUB linkage-name in the declaration of any routine 

which is to be used as a FORTRAN SUBROUTINE subprogram. 

This applies to all EXTERNAL ROUTINE declarations, for example, 
regardless of whether the routine is actually coded in BLISS or FOR- 
TRAN. This also applies, obviously, to the ROUTINE or GLOBAL ROU- 
TINE declaration if the routine is coded in BLISS. In both cases, it is also 
highly desirable to use the NOVALUE attribute as well. 

Use the FORTRAN FUNC linkage-name in the declaration of any rou- 
tine which is to be used as a FORTRAN FUNCTION subprogram. 

As with the FORTRAN__SUB linkage, this applies to EXTERNAL 
ROUTINE declarations as well as to ROUTINE and GLOBAL ROU- 
TINE declarations. 

If compatible and transportable interfacing to only PDP-11 and VAX-11 
FORTRAN systems is desired, then the FORTRAN linkage-name can be used 
for both SUBROUTINE and FUNCTION subprograms in BLISS-16 and 
BLISS-32. 
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Linkage-functions are executable-functions (see Section 5.2) that provide spe- 
cialized information about the actual-parameters used to call a routine. For 
example, linkage-functions can be used to code a routine that can be called 
with different numbers of actual-parameters in different routine-calls. 

13.6.1 Common Linkage-Functions 

There are three common BLISS linkage-functions: ACTUALCOUNT, 
ACTUALPARAMETER and ARGPTR. These functions can be used with all 
of the FORTRAN-related predeclared linkages in all BLISS dialects. They 
can also be used with some of the BLISS -related predeclared linkages. 
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13.6.1 .1 Definition — The common linkage-functions are defined as follows: 

ACTUALCOUNT( ) 

Restriction. Must be declared BUILTIN within the body of a routine 
whose linkage-attribute is defined with certain linkage-types. The link- 
age-types, and the predeclared linkages that are consequently permitted, 
are: 



Dialect 

BLISS-16 



Linkage-Type 

CALL 



Predeclared Linkages 

FORTRAN 

FORTRAN_SUB 

FORTRAN—FUNC 



BLISS-32 



CALL 



BLISS 
FORTRAN 
FORTRAN_SUB 
FORTRAN_FUNC 



BLISS-36 



F10 



FORTRAN_SUB 
FORTRAN_FUNC 



Value. Return the number of actual-parameters passed to the routine 
using STANDARD parameter-locations; parameters passed using REG- 
ISTER parameter-locations are not included in the returned value. 

For the predeclared linkages in all dialects, all parameters are passed 
using STANDARD parameter-locations and, consequently, ACTUAL- 
COUNT returns the number of actual-parameters. 

ACTUALPARAMETER( i ) 

Restrictions. The first restriction for ACTUALPARAMETER is the 
same as for ACTUALCOUNT above. 

The value of i must be in the range 1 to ACTUALCOUNT(). 

Value. Return the value of the i'th actual-parameter that was passed 
using STANDARD parameter-locations; parameters passed using REG- 
ISTER parameter-locations are not obtainable with this function. 

For the predeclared linkages in all dialects, all actual-parameters are 
passed using STANDARD parameter-locations, and, consequently, AC- 
TUALPARAMETER(i) returns the value of the i'th actual-parameter. 

ARGPTR( ) 

Restriction. The restriction for ARGPTR is the same as for ACTUAL- 
COUNT above. 

Value. Return the address of the argument block. 

13.6.1.2 Examples — The use of the linkage-functions permits routines to be 
written in a more general way. Consider, for example, a generalization of the 
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routine AVERAGE3 (Section 12.4.5), which accepts three parameters, to the 
routine AVERAGE, which accepts any number of parameters: 

ROUTINE AVERAGE = 
BEGIN 
BUILTIN 

actualcount » 
actualparameter; 

LOCAL 

L 5 . . 

L = i 

incr i from 1 to actualcount ( ) do 
l = . l + actualparameter ( , i ) 5 
.l/actualcount( ) 
end; 

Some calls on the routine AVERAGE and the value of these calls are given in 
the following list: 

Call Value 

AVERAGE ( 1 ,2 »3) 2 

AVERAGE < 2 »4 >6 »B f 10) 6 

AVERAGE (8) 8 

average () ??? (Invalid) 

In some cases a routine has a fixed and variable set of parameters. For exam- 
ple, consider the following routine, which calculates the difference between an 
expected value (the fixed part) and the average of a set of values (the variable 
part) : 

ROUTINE DELTA-AVERAGE (EXPECTED) = 
BEGIN 
BUILTIN 

actualcount » 
actualparameter; 

LOCAL 

Li 
L = 5 
INCR I FROM 2 TO ACTUALCOUNT ( ) DO 

L = .L + ACTUALPARAMETER* . I ) i 
.EXPECTED - ,L/(ACTUALCOUNT( )-l ) 
END5 

Some calls on the routine DELTA AVERAGE are: 

Call Value 

DELTA„AVERAGE(3 tl »Z ,3) 1 

DELTA_AVERAGE(B »2i4»GfB»10) 

delta„average(7) ??? (Invalid) 

delta-average ( ) ??? (Invalid) 

Observe in this example that explicit formal-parameters are not distinct from 
the parameters accessed by the linkage-functions. Specifically, .EXPECTED 
is equivalent to ACTUALPARAMETER(l). Consequently, the loop initial 
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value is 2, not 1, and the divisor in the next to last line is ACTUAL- 
COUNTO-1, not ACTUALCOUNTO. 

The ARGPTR linkage-function returns the address of the argument block of a 
routine-call. In some cases the argument block address passed in the argu- 
ment pointer register may not be left in that same register throughout the 
execution of the called routine. For example, in BLISS-36 this is usually done 
in the code compiled for a routine with the F10 linkage-type that calls another 
routine which also has the FlO linkage-type. The ARGPTR function provides 
a compatible means to obtain the address of the argument block in all 
dialects. 

13.6.2 BLISS-16 and BLISS-32 Linkage-Functions 

The NULLPARAMETER linkage-function (in BLISS-16 and BLISS-32 only) 
tests a parameter position of a call from a FORTRAN routine and returns true 
if the actual-parameter is a null or omitted parameter. See the PDP-11 and 
VAX-11 FORTRAN manuals for a description of null and omitted parame- 
ters. 

The NULLPARAMETER linkage-function is defined as follows: 

NULLPARAMETER( i ) 

Restriction. If i is not a formal-name then it is interpreted as an expres- 
sion and the value of i must then be greater than or equal to one. The 
linkage- type and predeclared linkages that are permitted are: 

Dialect Linkage-Type Predeclared Linkages 

BLISS-16 CALL FORTRAN 

FORTRAN_SUB 
FORTRAN_FUNC 

BLISS-32 CALL BLISS 

FORTRAN 

FORTRAN_SUB 

FORTRAN_FUNC 

Value. If i is a formal-name and the corresponding actual-parameter 
tested is null or omitted a value of one is returned; otherwise, a zero is 
returned. If i is an expression, a value of one is returned when: (a) i is 
greater than the number of actual-parameters or (b) i is not greater than 
the number, but the i'th actual-parameter has the value -1 in BLISS-16 
or in BLISS-32; otherwise, a zero is returned. 

13.7 Global Register Data Segments and Linkages 

A global register data segment is a data segment that is created and allocated 
in a given register in one routine and may be made available for use in other 
routines that it calls. Global register data segments are identified by name 
and both the calling and called routine must agree that a particular data 
segment is available. 
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A GLOBAL REGISTER declaration (Section 10.8) causes a global register 
data segment to be allocated. A global register data segment is a local data 
segment just like an ordinary register data segment — it is created on entry to 
the block in which it is contained and released on exit from that block. 
However, unlike an ordinary register data segment, a global data segment is 
available in called routines under certain circumstances. 

In order to pass a global register data segment to a called routine, the linkage- 
attribute for the called routine must contain the name of the data segment 
and its register assignment in its GLOBAL linkage-option. There may be 
more global register data segments available at a call than are given in the 
linkage for the call; however, every global register data segment given in the 
linkage must be available at the call. Only those global register data segments 
given in the linkage are available in the called routine. 

An EXTERNAL REGISTER declaration (Section 10.9) specifies that a global 
register data segment created in a calling routine is available for use. The 
declared name must be given in the linkage; however, not all global register 
data segments given in the linkage need be declared in an EXTERNAL 
REGISTER declaration. 

The linkage-attribute forms a bridge between calling and called routines. 
Consider the use of the global register data segment GRDS in the following 
example: 

7.IF ZBLISS(BLISSIG) OR XBL I SS ( BL I SS32 ) 
%THEN 
LITERAL 

GRDS-REG = 1 ; 
LINKAGE 

BRIDGE = 

/f.BLISSlG< JSR: GL0BAL(GRDS = GRDS-REG.) ) 
7,BLISS32(CALL: GLOBAL(GRDS = GRDS-REG > ) 5 
7.ELSE ! For BLISS-3S 
LITERAL 

GRDS_REG = S 5 
LINKAGE 

BRIDGE = PUSHJ: 

LINKAGE_REGS( IS » 13 * 1 > 
NOPRESERUE(Z i3 »4 »5> 
PRESERVE (0 »7 iB »9 »10 »1 1 »12 »14) 
GL0BAL(GRDS = GRDS-REG) i 
IF I 

FORWARD ROUTINE 

R0UT2: BRIDGE NOUALUE ? 

ROUTINE R0UT1 = 
BEGIN 
GLOBAL REGISTER 

GRDS = GRDS-REG i 
GRDS = o; 
R0UT2( ) ; 
.GRDS 

end; 
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ROUTINE ROUTZ: BRIDGE NOVALU'E = 
BEGIN 
EXTERNAL REGISTER 

GRDS ; 
GRDS = .GRDS + 1 i 
END ; 

First, the literal-name GRDS REG is bound to either the value 1 or the 

value 6, depending upon the compiler used for the compilation. This literal 
value is used to specify a register-number in several subsequent declarations. 
(The conditional-compilation constructs used in this example are described in 
Chapters 15 and 16.) 
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Next, the name BRIDGE is defined as a linkage-name with the global register 
data segment GRDS. This declaration also depends upon the compiler used 
for the compilation. (Note that the definition of BRIDGE for BLISS-36 
matches the default BLISS36C linkage except for the GLOBAL option, and 
thus is compatible with the default linkage.) Then, the forward-routine-decla- 
ration for ROUT2 uses the linkage-attribute BRIDGE. The calling routine 
ROUT1 allocates the global register data segment GRDS and sets it to 0. 
(Observe that ROUT1 does not need any special linkage-attribute in order to 
create the global register data segment.) ROUT1 then calls the routine 
ROUT2. ROUT2 increments the value of the global register data segment, 
and returns. The value of routine ROUT1 is the value of the global register 
data segment, 1. 

Because the information about the global register data segment is supplied by 
the linkage -attribute BRIDGE, the compiler can perform several consistency 
checks to verify that the global register data segment is being used correctly. 
In the above example, the compiler knows that ROUT2 uses a global register 
data segment and can, therefore, check that a call on that routine occurs 
within the scope of the global register declaration. Further, the compiler can 
check that the external register declaration for GRDS is within a routine with 
a linkage-attribute for the global register data segment GRDS. 

A global register data segment is a register that is, by convention, reserved for 
a particular use by a set of routines that function together as a package. For 
example, consider a file maintenance package. Typically, such a package 
consists of interface routines and internal routines. The interface routines 
establish the function to be performed by the file maintenance package (i.e., 
open, insert, and so on) and set up the appropriate environment. The internal 
routines perform the basic processing within the environment established by 
the interface. Part of that environment is often the establishment of one or 
more global register data segments. 

A file maintenance package is far too complex to illustrate here. Instead 
consider the following much smaller — and somewhat contrived — system. 
The module consists of a system of two global routines, VECMAXMIN and 
VECMAXMINAVG, each of which uses two other routines which are internal 
to the module. Both VECMAXMIN and VECMAXMINAVG are written to 
be callable from FORTRAN. Each actual-parameter to these routines must 
be the address of the desired FORTRAN variable or array. 

The first routine, VECMAXMIN, is called with the first parameter giving the 
base of an integer vector, and the second parameter giving the number of 
elements in the vector. The maximum value encountered in the vector is 
returned via the third parameter, while the minimum value is returned via 
the fourth parameter. The value of the routine is the difference between the 
maximum and minimum. 

The second routine, VECMAXMINAVG, is called with two parameters which 
are the same as the first two parameters of VECMAXMIN. Its value is the 
average of the maximum and minimum elements of the array. 
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The internal routine VECMAX1 searches a vector and returns the maximum 
value; and similarly, the internal routine VECMINl returns the minimum 
value. Routines VECMINl and VECMAXl each receive their two parameters 
as global register data segments, in registers that are appropriate for the 
respective, dialect-specific linkage definitions. (See the guidelines given fur- 
ther on concerning the preferred choice of registers for each target system.) 

MODULE VEC0PS( IDENT= '03' ) = 
BEGIN 

LITERAL 

VECREG = EBLISSlGt 1 ) 

ZBLISS32( 1 1 ) 

'/,BLISS3G( 12) f 
LENREG = ZBLISSiG(2> 

/f,BLISS32< 10) 

7,BLISS3G( 11)5 

LINKAGE 

BLISSTWOREG = 

7,BLISS1G( JSR; ) 
JGBLISS32(CALL: ) 

XBLISS3G< PUSH J; L I NK AGE_REGS ( 15*13*1) 
N0PRESERVE(2 >3 *4 »5) 
PRESERVE (0 »7.B»9»10»14>) 
GLOBAL (VEC = VECREG , LEN = LENREG)? 

FORWARD ROUTINE 

VECMAXMINs FORTRAN_FUNC » 
VECMAXMINAVG: FORTRAIM_FUNC » 
VECMAXl; BLISSTWOREG* 
VECMINl s BLISSTWOREG 5 

GLOBAL ROUTINE 

VECMAXMIN(VECADR tLENADR *MAXADR tMINADR) ; FORTRAN_FUNC = 
BEGIN 



GLOBAL 


REGISTER 








VEC 


= VECREG : 


REF 


VECTOR , 




LEN 


= LENREG? 






1 I) 
i 


"iitialize s 1 o b a 


1 registers 


VEC 


— ♦ 


VECADR? 






LEN 


= • 


•LENADR? 






! M, 

i 


ai n 


code 







♦MAXADR = VECMAXl ( ) 5 
♦MINADR = VECMINl ( ) ? 
. . MAX ADR- . ♦ MINADR 
END? 

GLOBAL ROUTINE VECMAXM I NAVG ( VECADR *LENAPR ) : FORTRAN_FUNC 
BEGIN 

GLOBAL REGISTER 

VEC = VECREG : REF VECTOR » 
LEN = LENREG? 

VEC = .VECADR? 
LEN = ♦ .LENADR ? 

(VECMAXl ( ) - VECMINl ( ) )/2 
END? 
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ROUTINE VECMP 


iXl % 


BLISSTWOREG 


BEGIN 






EXTERNAL 


REGISTER 


VEC: 


REF 


VECTOR * 


LEN? 






LOCAL 






MAXX ; 







MAXX = . VECCO] » 

DECR J FROM .LEN-1 TO 1 DO 

MAXX = MAX( ,MAXX » . MECC . J] ) 5 

.MAXX 
END? 

ROUTINE VECMIN1: BLISSTWOREG = 
BEGIN 



EXTERNAL 


REGISTER 


VEC: 


REF 


VECTOR » 


LEN5 






LOCAL 






MINN 


5 





MINN = . UECCO] i 

DECR J FROM .LEN-1 TO 1 DO 

MINN = MIN< .MINN » . UECC . J] ) 5 

.MINN 
ENDS 



END 
ELUDOM 



13.7.1 Discussion 



GLOBAL REGISTER and EXTERNAL REGISTER declarations in combi- 
nation with linkage-definitions that include a GLOBAL linkage-option pro- 
vide a controlled means to extend the scope of a register data segment from 
one routine into another routine. The restrictions help assure that this unu- 
sual dynamic extension of register scope is clearly documented and unlikely to 
be a source of error because of hidden effects. 

The optimization benefits from the use of global register data segments come 
about in two distinct ways. First, both the called and calling routines benefit 
from code efficiency that results from the use of a register instead of a tempo- 
rary (stack) location to hold the parameter value during the call. Second, the 
calling routine benefits from the fact that the global register value is still 
available in the same register after return from the called routine. No save 
and restore of the register contents is required around the call. 

The same conventions can (and must) be used to share register data segments 
between nested routine definitions. In this case, the convention allows the 
inner routine to access a "local" data segment of the outer routine in an 
efficient manner. (This capability is sometimes called "up-level addressing" 
in other languages and often requires complex and inefficient code.) Observe, 
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however, that there is no particular advantage to coding the called routine as 
a nested routine. Indeed, the convention works equally well between routines 
in separately compiled modules. 

The use of global registers is a useful and sometimes important optimization 
technique. Care must be taken, however, to assure that two independently 
developed parts of a program that use the technique do not inadvertently use 
register assignments that conflict when the parts are brought together. Global 
registers are not subject to the normal optimization strategies of the compiler 
and, consequently, may lead to worse, rather than better, code quality if too 
many are used. 

13.7.2 Guidelines for BLISS-16 

The many restrictions concerning the use of LINKAGE declarations and 
global register data segments are necessary to assure proper management of 
the machine registers at all times. 

Two guidelines are particularly recommended: 

1. The value return register should always be specified as non-preserved 
(which is the default). This will avoid the special restrictions related to 
this register. 

2. When planning the allocation of global register data segments, use con- 
tiguous registers beginning with register 1; for example, registers 1 and 2 
if two are needed. 

Note carefully that, because the PDP-11 has very few locally usable registers 
(relative to other target systems), the allocation of even one register as global 
over a large span of code will very likely decrease overall code quality. 

13.7.3 Guidelines for BLISS-32 

The many restrictions concerning the use of LINKAGE declarations and 
global register data segments are necessary to assure proper management of 
the machine registers at all times, especially during condition handling (see 
Chapter 17). One restriction in particular deserves special consideration when 
JSB routines and global register data segments are used together, namely: 

If a call to a routine with JSB linkage-type occurs in the scope of a global 
register data segment, then the given register-number of the data segment 
must be given in either a GLOBAL linkage-option or a NOTUSED linkage- 
option of the linkage of the called routine. 

That is, if a global register data segment is active at the point of a call to a 
JSB routine, the only permitted use of the register in the JSB routine is as a 
global register data segment; if not used that way, it must not be used at all. 

Some service routines in the VAX- 11 Run-Time Library use JSB linkage. By 
convention, these routines use a contiguous group of registers, none of which 
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are preserved, starting at register number 0. In light of this convention, and 
the above restrictions, the following two guidelines are suggested: 

1. When specifying the linkage of a routine with JSB linkage, give the 
locally usable registers as contiguous lower numbered registers starting 
at zero. Keep the set of locally usable registers as small as possible 
consistent with acceptable code quality. 

2. When planning the allocation of global register data segments, use con- 
tiguous higher numbered registers, that is, 11, 10, 9, and so on. 

A reasonable strategy is to divide the registers into groups so that JSB 
routines never locally use more than, say, registers through 7 and global 
register data segments are always specified in registers 8 through 11. This 
guarantees that no conflicts will arise in using JSB routines and global regis- 
ter data segments together. 

One additional guideline is strongly recommended, namely: registers and 1 
should always be specified as nonpreserved (which is the default). This will 
avoid the error prone special restrictions related to condition handling (see 
Section 13.3.2). 

13.7.4 Guidelines for BLISS-36 

The many restrictions concerning the use of LINKAGE declarations and 
global register data segments are necessary to assure proper management of 
the machine registers at all times. 

Two guidelines are particularly recommended: 

1. The value return register should always be specified as non-preserved 
(which is the default). This will avoid the special restrictions related to 
this register. 

2. When planning the allocation of global register data segments, use the 
highest-numbered contiguous set of registers available; for example, 12, 
11, 10, 9, and so on when using the BLISS36C type register conventions. 
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Chapter 14 
Binding 



Bound-declarations are different from most of the declarations discussed thus 
far because a bound-declaration defines a name in terms of other names and 
values. Bound-declarations do not involve the allocation of storage. Instead, 
they provide a name for a constant value, or an additional name and some- 
times a different interpretation for existing storage. 

A bound-declaration defines a name. The definition of a name consists of its 
scope, its value, and its attributes. The scope and attributes are determined 
in the usual way. However, the value of the name defined in the bound- 
declaration is determined from the value of an expression. 

A name can be defined by a bound-declaration to be a literal-name, a data- 
name, or a routine-name. The syntax diagram for bound-declarations is: 



bound-declaration 



(literal-declaration \ 

external-literal-declaration I 
bind-data-declaration f 

bind-routine-declaration / 



The syntax and semantics for each kind of bound-declaration are given in the 
following sections. 



14.1 Literal-Declarations 



A literal-declaration is used to define a name whose value is determined by a 
constant expression. After a name is defined in this way, it can be used to 
designate the constant expression. 

A literal-declaration can contribute to readability of a program. An example 
of this usage is 

LITERAL 

CAPACITY = 25 5 

This declaration allows the following assignment to be written: 

STUDENTS = .ROOMS * CAPACITY 
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In this expression, STUDENTS and ROOMS are data segment names and 
CAPACITY is the literal name declared above. The use of the literal-declara- 
tion makes clear the significance of the value 25. 

A literal-declaration is especially useful for defining a constant value that is 
used at several different places in a program. In the event that a different 
version of the program requires a different value for the constant value, the 
change can be made in just one place; namely, in the literal-declaration. An 
example of this usage is: 



LITERAL 

BUFFERSIZE 



2GG 5 



It is assumed that the size of the buffer changes from time to time and that 
this value is involved in computations throughout the program. A change in 
the value of BUFFERSIZE in this declaration automatically changes the 
value of all the occurrences of BUFFERSIZE within the program. 

14.1.1 Syntax 



literal-declaration 


(LITERAL ) literal item • 
( GLOBAL LITERAL J llteral ltem "" ' 


literal-item 


literal-name = literal-value 

( : literal-attribute ... ) 
( nothing ) 


literal-name 


name 


literal-value 


compile-time-constant-expression 


literal-attribute 


( range-attribute ) 

( weak-attribute J <= 32 Only 



14.1.2 Restrictions 

The value, n, of the bit-count expression in the range-attribute must lie in the 
range 1 < n < %BPVAL. 

The literal-value must be representable in the given number of bits. 

BLISS-32 ONLY 

The WEAK attribute may be specified only in a GLOBAL LITERAL decla- 
ration. 

14.1.3 Defaults 

If a range-attribute is not specified, then SIGNED(%BPVAL) is assumed. 
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14.1.4 Semantics 

A literal-declaration is processed by the compiler as follows: 

1. The literal- value expression is evaluated. 

2. The range-attribute is used to validate the representation of the literal- 
value. The bit-count expression is evaluated and the value obtained in 
Step 1 is checked to verify that it can be represented as a SIGNED or 
UNSIGNED value in the number of bits specified. 

3. If the literal-declaration is GLOBAL or GLOBAL with the weak-attrib- 
ute (BLISS-32 only), then the appropriate indicators are set for the 
linker. 

4. The literal-name is associated with the value represented in Step 2. 
Wherever the literal-name appears in the module, it is replaced by its 
associated value. 

14.1.5 Predeclared Literals 

Certain literal-names are predeclared in BLISS, as follows: 







Value in 






Name 


BLISS-16 


BLISS-32 


BLISS-36 


Significance 


%BPVAL 


16 


32 


36 


Bits per BLISS value 
(fullword) 


%BPUNIT 


8 


8 


36 


Bits per smallest ad- 
dressable unit 


%BPADDR 


16 


32 


18 or 30 


Bits per address value 


%UPVAL 


2 


4 


1 


Addressable units per 
BLISS value (%BPVAL 
divided by %BPUNIT) 



The value of %BPADDR in BLISS-36 is determined by the cpu-option setting 
of the ENVIRONMENT module-switch (Section 19.2); see the BLISS-36 
User's Guide for target-system environment information. 

The predeclared names just described can be used to enhance the transporta- 
bility of a program from one target system to another. See the appropriate 
BLISS user's guide, under "Transportability Guidelines", for further informa- 
tion. 

14.2 External-Literal-Declarations 

An external-literal-declaration gives a list of literal-names that are declared in 
other, separately compiled, modules. When the program that contains these 
modules is linked, the value of the external-literal-names is determined. 

External-literal-declarations are useful for providing mnemonic names for 
constant expressions that are common to the modules of a program. 
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An example of an external-literal declaration is: 



EXTERNAL LITERAL 

BLKSIZ: SIGNED(8) 5 



14.2.1 Syntax 



external-literal- 
declaration 


EXTERNAL LITERAL external-literal-item ,... ; 


external-literal- 
item 


literal-name ( : literal-attribute ... ) 
( nothing ) 


literal-name 


name 


literal-attribute 


( range-attribute ) 

\ weak-attribute J <= 32 Only 



14.2.2 Restrictions 

A name must not be declared EXTERNAL LITERAL unless it is declared 
GLOBAL LITERAL in some other block or module of the same program. This 
restriction does not apply, however, to a name that is declared with the weak- 
attribute in BLISS-32 (see Section 9.12). 

The range-attribute for an EXTERNAL literal-name must accommodate the 
value given for the literal in its GLOBAL literal-declaration. For further dis- 
cussion, see Section 9.10. 

14.2.3 Defaults 

If a range-attribute is not given, then SIGNED(%BPVAL) is assumed. 

14.2.4 Semantics 

An external-literal-declaration is processed by the compiler as follows: 

1. Each name in the list is identified as an EXTERNAL literal-name. 

2. If the WEAK attribute is specified, an indicator is provided for the 
linker (BLISS-32 only). 



14.3 Bind-Data-Declarations 



A bind-data-declaration is used to define another name for a data segment, or 
part of a data segment, that already exists. The bound name can have differ- 
ent attributes and can therefore depart from the original interpretation of the 
data segment. 
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An example of a bind-data-declaration appears in the following program frag- 
ment: 



OWN 



ALPHA: VECTOR C 20] 5 



BIND 



ALPHAT8] 5 



I NCR I FROM TO 20 DO 

ALPHAC.I] = *ALPHAE.I] * .Ai 

The name A is defined by the bind-data-declaration to be a fullword scalar 
with the same address as the ninth element of the vector ALPHA. A reference 
to A, therefore, is equivalent to, but more concise than, a reference to 
ALPHA[8]. 

In the example just given, the value of A can be determined at the time the 
program is linked since the address of the ninth element of the vector ALPHA 
is known at link time. An example of a binding that cannot be determined at 
link time is: 



BIND B 



ALPHAE2*. J-1] 



The contents of J is not known at link time and so the binding of B is deferred 
to execution time. Specifically, the binding occurs just before the evaluation 
of the block in which the declaration appears. The introduction of the name B 
can be efficient because no matter how often B is used during the evaluation 
of the block, the expression 2*. J-1 is evaluated only once. 

14.3.1 Syntax 



bind-data- 
declaration 


{ GLOBAL BIND } bind " date - item >" = 


bind-data-item 


bind-data-name = data-name-value 

( : bind-data-attribute ... ) 
( nothing ) 


bind-data-name 


name 


data-name-value 


expression 


bind-data-attribute 


/ allocation-unit \ <= 16/32 

1 extension-attribute 1 <= 16/32 

/ structure-attribute I 

\ field-attribute | 

I volatile-attribute 1 

V weak-attribute / <= 32 Only 



Binding 14-5 



14.3.2 Restrictions 

The data-name-value expression must be the address of a data segment that 
can be accessed within the scope of the declaration. 

The data-name-value expression must be a link-time-constant-expression if 
(1) the declaration begins with GLOBAL or (2) the declaration is at the 
outermost level of a module (and is not, therefore, contained in a routine- 
declaration). 

The data-name-value expression in a GLOBAL bind-data-declaration is lim- 
ited to a restricted subset of link-time-constant-expressions, in that it must 
not contain a name declared EXTERNAL, EXTERNAL ROUTINE or EX- 
TERNAL LITERAL unless that name is an operand of a compile-time-con- 
stant-expression (see Section 7.1.2, item 7). Furthermore, the data-name- 
value expression must not contain a name declared BIND, GLOBAL BIND, 
BIND ROUTINE or GLOBAL BIND ROUTINE unless the definition of that 
name satisfies this same restriction. 

A structure-attribute must not appear in a declaration that has an allocation- 
unit or an extension-attribute (BLISS-16/32 only). 

A field-attribute can appear only in a declaration that has a structure-attrib- 
ute. 

A weak-attribute can appear only in a GLOBAL bind-data-declaration 
(BLISS-32 only). 

14.3.3 Defaults 

If an allocation-unit is not given, fullword allocation is assumed (BLISS-16/32 
only). 

If a structure-attribute is not given, the name is assumed to be a scalar. 

14.3.4 Semantics 

A bind-data-declaration is processed as follows: 

1. The bind-data-name is associated with the attributes given either expli- 
citly or by default in the declaration. 

2. The value of the bind-data-name is determined. The time of evaluation 
depends on the kind of data-name- value expression given. If the expres- 
sion is not a link-time-constant-expression, it is evaluated just prior to 
the evaluation of the immediately containing block. 

14.4 Bind-Routine-Declarations 

A bind-routine-declaration is used to define another name for an existing 
routine. After a routine-name is defined in this way, it can be used in the 
scope of the bind-routine-declaration either by itself to designate the value of 
the routine-name or with a parenthesized list of parameters to indicate a call 
on the routine. 
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An example of a bind-routine-declaration is: 

BIND ROUTINE CALC = CALCULAT I 0N4 i 

It is assumed that CALCULATION4 is the name of a routine that is declared 
elsewhere, and under this assumption, the value of CALC can be determined 
at link time. 

Another example of a bind-routine-declaration is: 

BIND ROUTINE SR = (IF .A LSS THEN SNEG ELSE SP0S)i 

It is assumed that SNEG and SPOS are names of routines that are declared 
elsewhere. Because the expression to the right of the "=" operator is not a 
link-time-constant-expression, the value of SR is determined just before each 
evaluation of the block that contains the declaration. 

14.4.1 Syntax 



bind-routine- 
declaration 


( BIND ROUTINE ) 
(GLOBAL BIND ROUTINE J 

bind-routine-item ,... ; 


bind-routine-item 


bind-routine-name = routine-name-value 

( : bind-routine-attribute ... ) 
\ nothing ) 


bind-routine-name 


name 


routine-name-value 


expression 


bind-routine- 
attribute 


( novalue-attribute \ 
I linkage-attribute > 
( weak-attribute / <= 32 Only 



14.4.2 Restrictions 

The value of the routine-name-value expression must be the address of a 
routine that can be called within the scope of the bind-routine-declaration. 

The routine-name-value expression must be a link-time-constant-expression 
if (1) the declaration begins with GLOBAL or (2) the declaration is at the 
outermost level of a module (and is not, therefore, contained in a routine- 
declaration). 

The routine-name-value expression in a GLOBAL bind-routine-declaration is 
limited to a restricted subset of link-time-constant-expressions, in that it 
must not contain a name declared EXTERNAL, EXTERNAL ROUTINE or 
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EXTERNAL LITERAL unless that name is an operand of a compile-time- 
constant-expression (see Section 7.1.2, item 7). Furthermore, the routine- 
name-value expression must not contain a name declared BIND, GLOBAL 
BIND, BIND ROUTINE or GLOBAL BIND ROUTINE unless the definition 
of that name satisfies this same restriction. 

The WEAK attribute must be given only with a GLOBAL bind-routine-decla- 
ration (BLISS-32 only). 

14.4.3 Default 

If a linkage-attribute is not given and the bind-routine-declaration is in the 
scope of a LINKAGE switch, then the default linkage-attribute is the linkage- 
name given in the linkage-switch (see Sections 18.2 and 19.2). Otherwise, the 
default linkage-attribute is the predeclared linkage-name BLISS in BLISS-16 
and BLISS-32, or BLISS36C in BLISS-36. 

14.4.4 Semantics 

A bind-routine-declaration is processed as follows: 

1. The bind-routine-name is associated with the attributes given either 
explicitly or by default in the declaration. 

2. The value of the bind-routine-name is determined. The time of evalua- 
tion depends on the kind of routine-name-value expression given. If the 
expression is not a link-time-constant-expression, it is evaluated just 
prior to the evaluation of the immediately containing block. 
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Chapter 15 
Lexical Functions 



BLISS provides two groups of features that are concerned with the compile- 
time processing of a module: lexical-functions, described in this chapter, and 
macros, described in Chapter 16. Lexical functions and macros are closely 
related and share many common concepts and mechanisms. Consequently, 
the introduction to this chapter considers both together in an integrated way 
and lays the foundation for the description of macros in the next chapter. 

The lexical-functions perform basic operations on the text of the module; for 
example, the %STRING lexical-function gathers several lexemes into a single 
quoted-string lexeme, and the %CHARCOUNT lexical-function counts the 
characters in a given quoted-string. The example material in this chapter 
includes both lexical-functions and macros, since in practical use these two 
features are usually intertwined. 

Closely related to the lexical-functions is the lexical-conditional, which per- 
mits a programmer to indicate that a portion of a program is to be included or 
omitted depending on the outcome of a given compile-time test. Another 
related facility is the compiletime-declaration, which declares names whose 
values can be changed during compilation and which can control macro- 
expansion. 

All of these facilities depend on lexical processing, which is the first step in 
the compilation of a module. During lexical processing, lexemes are formed 
and interpreted, names are associated with their declarations, and the various 
kinds of lexical constructs are processed. 

This chapter is devoted to the lexical facilities of BLISS. The first section 
introduces lexical processing and the second section gives the quotation con- 
ventions. The next four sections describe lexical-expressions, lexical-functions 
(in general and in particular), and lexical-conditionals. The final section de- 
scribes the compiletime-declaration. 

15.1 Introduction to Lexical Processing 

The compilation of a module begins with lexical processing, which divides the 
module into lexemes, binds names to their associated declarations, and ex- 
pands macro-calls. 
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15.1.1 From Characters to Lexemes 

A module is supplied to the compiler as a sequence of characters and 
linemarks. As the module is processed, the characters and linemarks are 
collected to form lexemes. The various kinds of lexemes are described in 
Chapter 2. 

As an example of conversion to lexemes, consider the following module: 

MODULE EX = 

BEGIN 

GLOBAL 

X: VECTOR C 1024] ! 
END 
ELUDOM 

This module is presented to the compiler as a source file composed of the 
following characters: 

M, 0, D, U, L, E, blank, E, X, blank, =, linemark, 
B, E, G, I, N, linemark, 
G, L, O, B, A, L, linemark, 
blank, blank, blank, blank, X, :, 

blank, V, E, C, T, 0, R, [, 1, 0, 2, 4, ], ;, linemark, 
E, N, D, linemark, 
E, L, U, D, 0, M, linemark 

As the module is read by the compiler, it is converted into the following list of 
14 lexemes: 

MODULE , EX t = t 

BEGIN f 

GLOBAL f 

X f : t VECTOR » C » 1024 , ] » 5 , 

END t 

ELUDOM 

It is the lexemes that are important in BLISS, not the individual characters, 
and in the remainder of this chapter, modules are discussed as sequences of 
lexemes. That is, the division of modules into lexemes is taken for granted. 

15.1.2 Lexeme-by-Lexeme Processing 

The compiler works on one lexeme at a time. That is, the compiler does not 
read a new lexeme until it has done everything it can with the portion of the 
module it has already seen. This lexeme-by-lexeme processing is a fundamen- 
tal characteristic of BLISS. 

As an example of lexeme-by-lexeme processing, consider the following pro- 
gram fragment: 

OWN 

ALPHA 5 
ALPHA = 2? 

When the compiler encounters this fragment, it is already in the midst of a 
module. For purposes of discussion, assume that the compiler has already 
encountered, in an outer block, a declaration of ALPHA as a literal-name. 
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The first lexeme in the fragment is OWN. When the compiler reads this 
lexeme, it recognizes that the next lexeme will be a new declaration of some 
name, and it prepares for that situation. 

The second lexeme is ALPHA. Although ALPHA is already declared (accord- 
ing to the assumption made above), the compiler treats this occurrence of 
ALPHA as a new, overriding declaration of ALPHA. 

The third lexeme is a semicolon. When the compiler reads this lexeme, it 
knows that the declaration is complete. Therefore, the compiler fills in the 
various defaults for ALPHA, providing a complete declaration for the name. 

The fourth lexeme is another occurrence of ALPHA. Because of the context, 
the compiler knows that this occurrence of ALPHA is a use of the name rather 
than another declaration. Because the compiler is working on one lexeme at a 
time, it has the full declaration of ALPHA ready to apply to this use of 
ALPHA. And that is the main point of this example. 

The lexeme-by-lexeme processing of a BLISS program is quite natural and 
obvious for simple modules, such as the, example just given. However, in more 
complicated cases, there may be more than one "obvious" way to interpret a 
module, and the lexeme-by-lexeme rule must be invoked to determine what 
actually happens. 

15.1.3 Binding 

Every identifier that is not a reserved keyword can be used as a name. When 
an identifier is used as a name, it must be declared; that is, it must be 
associated with a declaration. Declarations can be implicit (supplied by the 
compiler) or explicit (written by the programmer). The process of associating 
a given use of a name with a declaration is called lexical binding. (The process 
of associating a declaration of a name with a storage address is also called 
binding, as discussed in Section 1.4. Binding in this sense, however, is not a 
concern of this chapter.) 

In some cases, there is more than one way to lexically bind a name. Consider 
the following example: 

LITERAL 

ABS = Oi 

♦ ♦ ♦ 

ROUTINE ALPHA(X): NOVALUE = 
BEGIN 
LOCAL 

ABS 5 
ABS = . ,X+1 i 
♦ X = . ABS* . ,X 5 
END 5 

In this example, there are three declarations of ABS. First, ABS is implicitly 
declared as the name of the absolute value executable function, as described 
in Chapter 5. Second, ABS is explicitly declared as LITERAL on the second 
line. Third, ABS is explicitly declared as LOCAL within the routine-declara- 
tion. According to the rules for scoping given in Section 8.2, the use of ABS in 
the assignment to .X is bound to the third (and most recent) declaration of 
ABS. 
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15.1.4 Expansion 

BLISS includes a facility for defining and using macros. Macros have names 
and the names are defined and given by declarations, just like other BLISS 
names. Thus the macro facility is an integral part of the BLISS language. 

A macro-declaration associates a sequence of lexemes, a macro-body, with a 
macro-name. Within the scope of the macro-declaration the macro-name can 
be used in a macro-call. During compilation, each macro-call is replaced by a 
copy of the macro-body. 

A macro can be parameterized; that is, each macro-call can supply actual- 
parameters that are substituted for formal-names in the macro-body. 

When the compiler encounters a macro-call, it first reads through the call 
itself, collecting and processing the actual-parameters. Then the compiler 
replaces the macro-call by its expansion. The expansion is a modified copy of 
the macro-body that is given in the declaration of the macro. 

A simple example is: * 

MACRO 

PROD(X) = ( ( (>() + l )*< (X) -1 ) ) li 

* t t 

B = PR0D(2*A) 5 

Here, the macro-call is "PROD(2*A)" and the macro-body is 
"(((X)+1)*((X)-1))". After the macro-call is expanded, the assignment to B 
becomes: 

B = ( ( (2*A) + 1 )*( (2*A) -1 ) ) 5 

The term "expansion" reflects the fact that macros are often used by a pro- 
grammer as a short way to express a long construct. Indeed, in the example 
above, the expansion is considerably longer than the macro-call that it re- 
placed. 

In general, however, "expansion" refers to the replacement of one sequence of 
lexemes by another during compilation. There are four kinds of expansion in 
BLISS: 

• A lexical-function is replaced by its expansion, as described in Sections 
15.4 and 15.5. 

• A lexical-conditional is replaced by its lexical-consequence or lexical- 
alternative, as described in Section 15.6. 

• A macro-call is replaced by the corresponding macro-body, and the for- 
mal-parameters in the macro-body are replaced by the corresponding 
actual-parameters, as described in Sections 16.2 and 16.3. 

• A require-declaration or library-declaration is replaced by the file it des- 
ignates, as described in Sections 16.5 and 16.6. 

The idea of expansion is a simple one, except for one problem: how is the idea 
of replacing one entire sequence of lexemes with another, all at once, consist- 
ent with the lexeme-by-lexeme processing described in Section 15.1.2? The 
answer to this question requires a brief consideration of the organization of the 
compiler. 
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The compiler processes a module in several stages; lexical processing is the 
first stage. The lexical processing stage of the compiler reads lexemes from the 
source file, collects lexemes until it can perform some lexical processing, 
passes the resulting lexemes to the next stage of the compiler, and, once 
again, reads lexemes from the source file. 

The compiler can be thought of as working from a single sequence of lexemes, 
the input stream as follows: 

• At the beginning of compilation, the input stream is the given module. 

• Each time the compiler can do nothing more without another lexeme, it 
takes a lexeme from the head of the input stream. 

• Whenever the compiler has accumulated a construct that can be ex- 
panded (such as a lexical-function or a macro-call), it processes that 
construct and places the resulting sequence of lexemes at the head of the 
input stream. 

• Whenever the lexical-processing stage of the compiler has accumulated a 
construct that cannot be further expanded (such as a keyword or a plus 
symbol), it passes that construct on to the next stage of the compiler. 

• When the input stream is empty, compilation is complete. 

The method of lexical processing just described is simplified, but only in the 
following way: it suppresses those details of the BLISS compiler that, while 
they are important for efficient operation of the compiler, do not affect the 
meaning of the program or the object code produced by the compiler. 

15.1.5 An Example of Lexical Processing 

The following module will be used as an example of lexical processing: 

MODULE SI = 

BEGIN 

REQUIRE 

'STDMAC ' 5 
GLOBAL BIND 

PI = STR8( 'ABC ) » 

P2 = STR8( 'ABCDEFGHIJKLM' ) 5 
END 
ELUDOM 

The fourth line of this module references the file named STDMAC. The 
contents of that file is assumed to be: 

MACRO 

STR8(S) = 

11F 7,CHARC0UNT(S) GTR 10 

"Jf.THEN "JSWARINK 'STR8 PARAM TOO LONG') IF I 

PLIT( XEXACTSTRINGt 10 t%C ' '»S) ) 
1 5 

A detailed trace of the lexical processing of the module follows. The binding of 
names is described, expansions are performed, and the state of the compila- 
tion is given after each expansion. 

The compiler starts with MODULE and reads lexemes from the input stream. 
The identifier SI is treated in a special way because it is the module name; it 
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does not affect the meaning of the program. When the compiler reads the 
semicolon on the fourth line, it knows that it has reached the end of a com- 
plete require-declaration. In accordance with the definition of require-declara- 
tions (Section 16.5), the compiler expands the require-declaration by placing 
the contents of the designated file at the head of the input stream. 



At this point, the state of compilation is: 



MODULE SI = 
BEGIN 
-=> MACRO 

BTR8(S) = 

7, IF /CHARCOUNT(S) GTR 10 
'/.THEN /.WARN* 'STR8 PARAM TOO LONG') IF I 
PLIT< 7,E><ACTSTRING< 10 >1C ' '»S) ) 
'I ; 
GLOBAL BIND 

PI = STR8( 'ABC ' ) t 
P2 = STR8( 'ABCDEFGHI JKLM' ) 3 
END 
ELUDOM 

The arrow "==>" at the beginning of the third line is a marker used in this 
explanation of lexical processing. Everything from the beginning of the mod- 
ule up to the arrow has passed through lexical processing and everything from 
the arrow through the end of the module is the input stream. The lexeme that 
immediately follows the arrow is the head of the stream. 

The compiler continues processing lexemes, starting with MACRO. The oc- 
currence of STR8 declares that name as a macro-name. The first occurrence of 
S declares that name to be the first (and only) formal parameter of STR8. The 
second and third occurrences of S are bound to this declaration. When the 
compiler reads the percent lexeme, it knows that it has read a complete 
macro-definition. It associates the macro-body with the name STR8. 

The compiler continues, starting with GLOBAL. The occurrence of PI de- 
clares that name to be a GLOBAL BIND name with a given value. The 
occurrence of STR8 is bound to the macro-declaration of the same name. 
When the compiler reads the right parenthesis that follows 'ABC, it knows 
that it has read a complete macro-call. In accordance with the definition of 
ordinary macros (Section 16.3), the compiler expands the macro-call by plac- 
ing a copy of the macro-body at the head of the input stream and replacing 
each formal-parameter in the copy by the corresponding actual-parameter. 



At this point, the state of compilation is: 



MODULE SI = 

BEGIN 

MACRO 

STR8(S) = 

'/IF /CHARCOUNT(S) GTR 10 
/THEN '/WARN('STR8 PARAM TOO LONG') IF I 
PLIT( 7.EXACTSTRING( 10 »/C ' ' iS> ) 
7, 5 
GLOBAL BIND 
PI = 
= = > 21F 7,CHARC0UNT( 'ABC ' > GTR 10 

/THEN 7,WARN('STR8 PARAM TOO LONG') 2f.FI 
PLIT( /EXACTSTRING( 10 tlC ' '.'ABO ) , 
P2 = STR8( 'ABCDEFGHI JKLM' ) 3 
END 
ELUDOM 
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The compiler continues, starting with the first lexeme, %IF, of the lexical- 
conditional. When the compiler reads the right parenthesis that immediately 
follows 'ABC, it knows that it has read a complete %CHARCOUNT lexical 
function. In accordance with the definition of that function (Section 15.5.2), 
the compiler expands the function by counting the number of characters in 
the actual-parameter 'ABC and placing a numeric-literal that represents the 
count at the head of the input stream. Now the state of compilation is: 

GLOBAL BIND 
Pi = 

11 F = = > 3 GTR 10 

ITHEN 7,WARN< 'STR8 PARAM TOO LONG') XFI 

PLIT( /f,EXACTSTRING< 10 tlC ' '.'ABO ) . 
P2 = STR8( 'ABCDEFGHIJKLM') i 

♦ ♦ ♦ 

When the compiler reaches %THEN, it has evaluated the lexical-test of a 
lexical-conditional; because 3 is not greater than 10, the test is not satisfied. 
In accordance with the definition of lexical-conditionals (see Section 15.6), the 
compiler skips the remainder of the lexical-conditional. The state of compila- 
tion is: 

♦ ♦ t 

GLOBAL BIND 

PI = = = > PLIT( XEXACTSTRING( 10 »'£C' '.'ABO ) » 
P2 = STR8( 'ABCDEFGHIJKLM' ) i 

♦ ♦ * 

The compiler continues, starting with PLIT. The occurrence of %EXACT- 
STRING is recognized as a lexical-function name, and when the compiler 
reads the right parenthesis that follows, it knows it has a complete %EXACT- 
STRING lexical function. In accordance with the definition of that function 
(Section 15.5.2), the compiler makes 'ABC into a ten-character quoted-string 
by filling at the right with blanks, and places this expansion at the head of the 
input stream. 

The state of compilation is: 

♦ 4 » 

GLOBAL BIND 

PI = PLIT< = = > 'ABC ' ) , 
P2 = 5TR8< 'ABCDEFGHIJKLM ') 5 

The compiler continues, and reaches the declaration of P2. This declaration is 
treated similarly to that of PI; however, because the string given for P2 
contains more than 10 characters, the test in the compilation-expression is 
satisfied and the compilation arrives at the following state: 

♦ ♦ ♦ 

GLOBAL BIND 

PI = PLIT( 'ABC ' ) t 

P2 = 

= = > 'JKHARIsK 'STR8 PARAM TOO LONG') 'JKFI 

PLIT( XEXACTSTRING< 10 tXC ' ' > ' ABCDEFGH I JKLM ' ) >i 

The compiler expands the %WARN lexical-function by generating the warn- 
ing message "STR8 PARAM TOO LONG", incrementing the warning count, 
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and then placing the empty sequence (that is, nothing at all) at the head of 
the input stream. The compiler skips the %FI, which is the end of the lexical- 
conditional. Now the state of compilation is: 

GLOBAL BIND 

PI = PLIT( 'ABC ' ) t 

P2 = 

= = > PLIT( 7,EXACTSTRING( 10 »7,C ' ' » ' ABCDEFGH IJKLM ' ) )5 

♦ ♦ ♦ 

The compiler continues to the %EXACTSTRING lexical-function, which it 
expands as follows: 

♦ ♦ ♦ 

GLOBAL BIND 

PI = PLIT( 'ABC ' ) » 

P2 = PLIT( 'ABCDEFGHIJ' ==> )! 

♦ ♦ ♦ 

The compiler continues to the end of the input stream without performing any 
further binding or expansion. The result is the same as the result of compiling 
the following module: 

MODULE SI = 
BEGIN 
GLOBAL BIND 

PI = PLIT( 'ABC ' ) t 

7,WARN('STR8 PARAM TOO LONG') 

P2 = PLIT( 'ABCDEFGHIJ ' ) 5 
END 
ELUDOM 



15.2 Quotation 



(This section presents material that is difficult to understand. One approach 
to this section is to read it casually before reading the rest of the chapter and 
then to read it again carefully.) 

BLISS has facilities for quotation. Quotation postpones until a later lexical 
scan the binding of a name and the expansion of a lexical-function or macro- 
call. 

The need for quotation in BLISS is not obvious. The argument in favor of 
being able to quote a name is as follows: 

1. Some names are processed more than once. For example, a name in a 
macro-body is processed once as part of the macro-declaration and 
then, a second time, as part of the expansion of a macro-call. 

2. A particular use of a name can only be bound to one declaration. There- 
fore, a name that is processed twice could be bound in two different 
ways, and a choice must be made. 

3. A simple rule for choosing among bindings, such as "always bind a 
name the first time it is processed", is not flexible enough. 

4. Therefore, some mechanism is necessary to specify when binding shall 
occur. This mechanism is the quotation facility. 
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The BLISS quotation facility has two parts: the quotation rules, and the 
quote-functions. Each quotation rule states that in a particular context cer- 
tain kinds of names are bound or not bound. The quote -functions override the 
quotation rules and tell the compiler, for example, to quote a particular name 
regardless of the applicable quotation rules. The quotation rules are given 
later in this section. 

A preliminary example of the BLISS quotation facility is: 



OWN 

v : 








A 1 

LITERAL 

MARK 
MACRO 

M = 


= a; 

MARK + 


7, UNQUOTE 


MARK 1 5 


+ ♦ ♦ 

BEGIN 
LITERAL 

MARK 
X = Mi 


= 55 







END 

The interesting part of the example is the binding of the uses of MARK. A 
detailed discussion follows. 

The name MARK is declared twice, both times as LITERAL, but with differ- 
ent values. Each use of MARK must be bound to one or the other of these 
declarations. 

The only uses of MARK are in the declaration of the macro M. There are two 
uses and they are handled in two different ways. The first occurrence is not 
bound because one of the BLISS quotation rules (defined in Section 15.2.2) 
states that in the macro-body of a macro-declaration only a macro formal- 
name is bound. The second occurrence is bound because the %UNQUOTE 
function (defined in Section 15.5.13) overrides the rule just stated and forces 
binding. After processing, the macro-body is: 

MARK (not bound yet) + MARK (bound to LITERAL 4) 

This macro-body is associated with the macro-name M. 

Later in the processing of the example, the compiler replaces the macro-call 
on M with its expansion, and begins to process the expansion. This time 
around, the first MARK is bound because the quotation rules permit it. The 
second MARK is already bound and, because a name is never bound for a 
second time, is left as it is. After processing, the expansion is: 

MARK (bound to LITERAL 5) + MARK (bound to LITERAL 4) 

Thus the assignment statement is compiled as assigning 9 to X. 

In this example, the application of the quotation rules to the binding of names 
has been illustrated. They also apply to the expansion of lexical-functions and 
macro-calls. 
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15.2.1 Quote Levels 

The quotation rules of BLISS are organized around three quote levels. At any 
given time during compilation of a module, a particular quote level applies to 
the lexemes being read from the input stream. As compilation proceeds, the 
quote level changes depending on the language construct that is being com- 
piled. 

The quote levels are numbered from 1 to 3. They are: 

1. Normal-Quote. This level applies to any portion of a module not cov- 
ered by the following quote levels. 

2. Name-Quote. This level applies to lexical contexts in which it is "natu- 
ral" to ignore most applicable declarations. The portions of a module 
processed at name-quote level are: 

a. A name that is about to be declared (explicitly or implicitly). Specif- 
ically, (1) a name that begins a definition within a declaration, or (2) 
a name that appears in the formal-name-list of a routine, structure, 
or macro declaration. 

b. A name that appears in (1) a name-quote actual-parameter of a 
lexical-function or (2) any actual-parameter of a macro-call. 

c. An unreserved keyword in a context in which an unreserved keyword 
is required. An example is a module-switch in a module-head (de- 
scribed in Section 18.1.1), where the context makes it clear that a 
keyword is being used as a switch. (The BLISS keywords are listed 
in Appendix B.) 

3. Macro-Quote. This level applies primarily to a macro-body in a macro- 
declaration. It also applies to a keyword-default-actual-parameter (Sec- 
tion 16.2.1). 

If more than one of the preceding levels could apply to a given context, the 
quote level with the highest number is chosen. 

15.2.2 Quotation Rules 

The quotation rules determine the binding of names and the expansion of 
both macro-calls and lexical functions. There are three quotation rules, one 
for each quote level, as follows: 

1. At normal-quote level, bind every name. 

At this level, expand every macro-call and lexical-function. 

2. At name-quote level, bind macro-names. That is, bind a name only if 
the binding, performed in the usual way, associates the name with a 
macro-declaration. At this level, expand every macro-call and lexical- 
function. 



15-10 Lexical Functions 



3. At macro-quote level, bind macro-formal-names. That is, bind a name 
only if the binding, performed in the usual way, associates the name 
with the (implicit) declaration of a macro-formal-name. 

At this level, expand only the quote lexical-functions; that is, 
%QUOTE, %UNQUOTE, and %EXPAND. 

The quote-functions, described in Section 15.5.13 are specifically designed to 
override the rules above. However, a quote-function only applies at a specific 
place in a program. For example, the %QUOTE function postpones applica- 
tion of the bind operation to a name that immediately follows the function, 
even though the quotation rules may call for binding of that name. 



15.3 Lexical-Expressions 



A module is presented to the compiler as a source file composed of characters 
and linemarks. During lexical processing, the characters are grouped into 
lexemes and then the lexemes are grouped into lexical-expressions. 

A lexical-expression can be a single lexeme. Examples are: 
+ The plus symbol 

module The keyword that begins a module 

alpha A name (not declared MACRO) 

329 A decimal-literal 

'ABC A quoted-string 

Each of these examples is not only a single lexeme but is also primitive; that 
is, it is not expanded into some other sequence of lexemes during lexical 
processing. 

Some examples of lexical-expressions that are more complicated are: 

iascicabc A string-literal 

*.ch arcount ( ' abc ' ) A lexical-function 

% I f scswiTCHEStDEBUG) A lexical-conditional with two nested lexi- 

zthen zwarn( 'banc ) xfi cal-functions 

betao » 'abc ) A macro-call (assume BETA is declared 

MACRO) 

require 'TBS' ; A require-declaration 

library 7,string< 'xyz ' »o> ; A library-declaration with a nested lexi- 
cal-function 

All of these lexical-expressions are composed of two or more lexemes. The first 
example is a %ASCIC string-literal and is primitive. The second example is a 
%CHARCOUNT lexical-function and is nonprimitive; it is expanded to 3, 
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which is a primitive lexical-expression. The remaining examples are all non- 
primitive, but their expansion requires contextual information not given here. 

An example of a sequence of lexical-expressions that constitutes a complete 
module is: 

MODULE Q = 

BEGIN 

MACRO 

PACK (X) 
GLOBAL BIND 

MESSAGE 
END 
ELUDOM 



UPLITC/.CHARCOUNTCX) »>() i 
PACK ( 'HELLO' ) 5 



This module is mainly composed of primitive, single-lexeme lexical-expres- 
sions. The two exceptions are %CHARCOUNT(X) on the fourth line and 
PACK('HELLO') on the sixth line. The first nonprimitive lexical-expression, 
%CHARCOUNT(X), occurs within a macro-body and, therefore, is processed 
at macro-quote level; it is not expanded during macro definition, but is 
treated simply as a single-lexeme sequence. The PACK('HELLO') lexical- 
expression is a macro-call, and its expansion is: 

UPLIT(7,CHARC0UNT( 'HELLO ' ) , 'HELLO ' ) 

This expansion includes the nonprimitive lexical-expression 
%CHARCOUNT('HELLO'). This is a lexical-function at normal-quote level 
and its expansion is 5. 

This section introduces the various kinds of lexical-expressions in BLISS and 
thus prepares for detailed descriptions in the remaining sections of this chap- 
ter. 



15.3.1 Syntax 



lexical-expression 



( primitive 



nonprimitive 



primitive 



delimiter 

keyword 

name 

numeric-literal 

string-literal 



nonprimitive 



lexical-function 

lexical-conditional 

macro-call 

require-declaration 

library-declaration 
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The primitive lexical-expressions are described in other parts of this manual; 
specifically, the delimiters are listed in Section 2.2.1, the keywords are listed 
in Appendix A, and the names, numeric-literals, and string- literals are de- 
scribed in Chapter 4. 

Under certain conditions, a name, by itself, is also a macro-call; in that case, 
the name is nonprimitive. 

15.3.2 Semantics 

The fundamental lexical rule of BLISS is: 

A given sequence of lexemes is a valid BLISS module if and only if the 
expansion of nonprimitive lexical-expressions produces a sequence of lex- 
emes that satisfies the definition of module given in Chapter 19. 

This rule joins together the description of lexical-expressions given in this 
chapter and the definition of a module given in Chapter 19. (That definition 
of a module includes, by reference, most of the other chapters of this manual.) 

The semantics of the various nonprimitive lexical-expressions are given in 
later sections of this chapter. 

A few remarks about numeric- and string-literals as lexical-expressions are 
necessary. These remarks are presented here rather than in Chapter 4 because 
they are closely related to the concepts of lexical processing. 

15.3.2.1 Types of Numeric-Literals — The numeric-literals, as defined in 
Section 4.2, can be classified as follows: 

Full word Type: 

Unsigned Decimal-Literal 

Integer-Literal 

Character-Code-Literal 
Single-Precision-Float Type: 

Single-Precision-Float-Literal 
Double-Precision-Float Type: 

Double-Precision-Float-Literal 

Different numeric-literals of the same type can be used interchangeably, but 
numeric-literals of different types cannot. For example, if a decimal-literal is 
called for in the syntax, then an integer-literal can be used instead, but a 
single-precision-float-literal cannot. 

This rule about interchangeability of numeric-literals does not say anything 
new about BLISS, but draws together assertions that are made in several 
different places in this manual. 
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15.3.2.2 Types of String-Literals — The string-literals, as described in Section 
4.3, can be classified as follows: 

Uncounted ASCII Type: 

Quoted-String (without preceding string-type) 

%ASCII String-Literal 

%ASCIZ String-Literal 
Counted ASCII Type: 

%ASCIC String-Literal (BLISS-16/32 only) 
Radix-50 Type: 

%RAD50_11 String-Literal (BLISS-16/32 only) 

%RAD50_10 String-Literal (BLISS-36 only) 
Sixbit Type: 

%SIXBIT String-Literal (BLISS-36 only) 
Packed Decimal Type: 

%P String-Literal (BLISS-16/32 only) 

Different string-literals of the same type can be used interchangeably, but 
string-literals of different types cannot. For example, if a quoted-string is 
called for, then a %ASCII string-literal can be used but a %ASCIC string- 
literal cannot. 

BLISS permits this interchange of uncounted string-literals because each of 
them represents a sequence of ASCII characters. (The at the end of a 
%ASCIZ literal is thought of as the ASCII character called "null", which has 
code 0.) 

The interchangeability of uncounted ASCII literals does make a slight addi- 
tion to the language. Consider the definition of the %ASCIC string-literal 
(BLISS-16/32 only) given in Section 4.3: 

/ASCIC quoted-string 

Because of the interchangeability of uncounted ASCII literals, the quoted- 
string can be replaced by an ASCIZ string-literal, and the result is: 

1 ASC I C '/ASCIZ quoted -string 

Thus the following construct is a valid %ASCIC string-literal in BLISS-16 or 
BLISS-32: 

/ASCIC '/.ASCIZ 'ABC 

This literal has a different interpretation than either %ASCIC'ABC or 
%ASCIZ'ABC. It is encoded in five bytes. The first byte contains the number 
of characters, 4, in the character sequence. The next three bytes contain the 
ASCII codes for A, B, and C. The final byte contains 0, which is the ASCII 
code for the null character. 

Some further applications of interchangeability of uncounted ASCII literals 
are: 

IB /ASCI I ' 1 101 1 ' 

/C '/.ASCI I 'Q ' 

/ASCII /ASCIZ /ASCI I 'ABC 
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15.3.2.3 Numeric- and String-Literals — Except for the decimal-literal and 
quoted-string, the numeric- and string-literals are all composed of two lex- 
emes. Each of those lexemes can be produced by nonprimitive lexical-expres- 
sions. An example is the following program fragment: 

MACRO 

OCT(N) = 10 XSTRING(N) %i 

0CT(23) 

When the macro-call OCT(23) is expanded, the result is: 

10 '^STRING (23) 

Then the %STRING lexical-function is evaluated and the result is: 

10 '23' 

Thus the final value is 19 (decimal). 

15.3.3 Discussion 

Some nonprimitive lexical-expressions have an 'empty' expansion, that is, 
they do not produce any lexemes. They are used for their side-effects in 
controlling the compilation process. Two examples are the %UNQUOTE and 
%WARN lexical-functions discussed previously. 

Other nonprimitive lexical-expressions have non-empty expansions, as do 
most of the lexical-expressions introduced so far. Almost all instances of this 
"expanding" type of nonprimitive lexical-expression can, in principle, be re- 
placed by an equivalent sequence of primitive lexical-expressions. Such 're- 
placeable' lexical-expressions do not produce any results that (again, theoreti- 
cally) could not be obtained without them. Their purpose is to facilitate both 
conditional compilation and the writing of macros. Also, they often radically 
reduce the effort required to achieve a given result, and can be used to en- 
hance the clarity of a module. 

It is useful to examine those few cases in which a nonprimitive lexical-expres- 
sion cannot in any way be replaced by an equivalent primitive lexical-expres- 
sion sequence. There are three such cases. Each of them is rather specialized, 
and all of them involve lexical-functions. They are: internal-only character 
sequences, excessively-long character sequences, and internal-only names. 

An internal-only character sequence is a character sequence that is not com- 
posed entirely of printing characters, blanks, and tabs. Such character 
sequences can be represented by means of the %STRING and %CHAR lexi- 
cal-functions, but cannot, according to Section 4.3, be represented by a 
quoted-string. 

As an example, consider the character sequence 

A, carriage-return, line-feed, B 

This sequence can be represented as follows: 

%STRING( 'A ' >7,CHAR( 13) t'Z,CHAR( 10) t 'B' ) 
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The lexical-functions %STRING and %CHAR are defined later, in Section 
15.5.2. In this example, %CHAR(13) and %CHAR(10) represent the trouble- 
some characters, and the %STRING function joins the four characters into a 
single sequence. That sequence cannot be represented by a quoted-string 
because a quoted-string cannot include a carriage-return or a line-feed. Thus 
the uses of the %STRING and %CHAR functions are essential in this exam- 
ple. 

An excessively-long character sequence is one that contains more characters 
than can be represented on one line by a quoted-string. Such a character 
sequence can be represented on several lines by means of %STRING as fol- 
lows: 

"/.. S T R I N G ( 'A line of many characters'* 
'Another line of characters') 

Again, %STRING is essential in this example. 

An internal-only name is a character sequence that must be used as a BLISS 
name but that does not satisfy the syntax for a BLISS name. An example is 
XYZ.A, which is a valid assembler name but not a valid BLISS name. In 
BLISS, this name can be represented only as: 

7,NAME( 'XYZ.A ' ) 

The lexical-function %NAME is defined later, in Section 15.5.4. 

15.3.4 Pragmatics 

The description of the lexical-processing stage of the compiler given in this 
chapter is correct with respect to the results of compilation, but does not 
reflect techniques that make the compiler itself more efficient. One such 
technique involves the use of internal encoding of lexemes, and another the 
use of multiple input streams for the expansion of lexical-expressions. 

The latter technique merits some discussion, since it pertains to the scanning 
of lexemes. The compiler does not, in fact, maintain a single input stream into 
which the expansion of every lexical-expression is inserted. Instead, the com- 
piler maintains several input streams. The principal input stream is, of 
course, the file for the module that is being compiled. However, a new input 
stream is introduced each time an expansion occurs. For example, after a 
macro-call has been processed, the corresponding macro-body becomes a new 
input stream. Even the replacement of a formal-name in a macro-body by the 
associated macro actual-parameter is done by treating the actual-parameter 
as a new input stream. 

When a new input stream is introduced, input from the old input stream is 
suspended. Lexemes are taken from the new input stream until it terminates. 
This new stream can itself contain lexical-expressions whose expansion may 
introduce further new streams. When the end of an input stream is reached, 
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the previous input stream is restored. Thus the input streams are nested, and 
the initial input stream (the module file) is always the final input stream. 

15.4 Lexical-Functions in General 

A lexical-function is processed by the compiler. The result is a sequence of 
lexemes that is the expansion of the lexical-function. The expansion then 
becomes input to the compiler and is processed in its turn. 

It is important to distinguish between the evaluation of a computational 
expression and the expansion of a lexical-function. A computational expres- 
sion yields a value, and that value can be used in the evaluation of other 
expressions. In contrast, a lexical-function yields a sequence of lexemes, and 
that sequence can be used as input to the compiler. 

It is also useful to distinguish between lexical-functions and macro-calls. Both 
return a sequence of lexemes, but a lexical-function invokes an operation that 
is built into BLISS, whereas a macro-call invokes an operation that must be 
defined in a macro-declaration. Thus lexical-functions and macro-calls are 
related in the same way that executable-functions and routine-calls are re- 
lated. 

Certain parameters of lexical-functions can be expressions, but every such 
expression must be a compile-time-constant-expression. This restriction re- 
flects the fact that all lexical-functions must be fully processed during compi- 
lation. 

Each lexical-function begins with a keyword that, in turn, begins with a 
percent character; for example, %STRING and %CHAR. 

A few examples of lexical-functions follow: 

Lexical-Function Expansion 

'/STRING* 'A ' » 'B' t 'C ' ) 'ABC 
'/■STRINGt ')< ' »24) 'X24' 

2f.CHARC0UNT( 'ABC ' ) 3 

'/.number* '-000S2' ) -62 (coded internally as one lexeme) 

These are simple examples: the expansion of each of these lexical-functions is 
a single lexeme. 

Some lexical-functions can return a sequence that is more than one lexeme in 
length. A simple example is: 

Lexical-Function Expansion 

'/.EXPLODE ( 'ABC ) 'A','B','C 

In this case, the expansion consists of five lexemes (three quoted-strings and 
two commas). 
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Some lexical-functions are replaced by nothing (that is, an empty sequence of 
lexemes). For example, 

Y = .A+XPR INK 'CHECK POINT 20')F(X)5 

produces the same object code as 

Y = . A + FOO ; 

However, the first version causes the informational message 'CHECK POINT 
20' to be included in the output listing of the compiler. 

Lexical functions can be nested. An example is: 

'/.STRING* 'A' »'/.CHARC0LIIMT< 'XYZ' ) , 'B ' ) 

Expansion of the %STRING function begins with expansion of the nested 
function, %CHARCOUNT giving: 

'JKSTRING( 'A ' ,3 » 'B ' ) 

then the 96STRING function itself is expanded, giving: 

'A3B ' 

This quoted-string is the final expansion of the nested lexical functions. 

This section gives the general definition of lexical functions, without defining 
any particular function. Specific definitions are given in the next section. 

15.4.1 Syntax 



lexical-function 


lexical-function-name 

( (lexical-actual-parameter,...) \ 
I lexeme > 
(. nothing / 


lexical- 
function-name 


%name 


lexical-actual- 
parameter 


( lexeme ... ) 
( nothing ) 



15.4.2 Restrictions 

A lexical-function must conform syntactically to one of the specific lexical- 
function definitions given in the next section, Section 15.5. For example, the 
%DECLARED function requires just one parenthesized parameter, and that 
parameter must be a single lexeme, specifically a name. 
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Each lexical-function-name is a reserved keyword. It must not be declared 
and cannot be used for any other purpose. 

15.4.3 Semantics 

The processing of a lexical-function is performed as part of the compilation of 
a module. Processing begins when the compiler calls for the next lexeme of the 
input stream and that lexeme is recognized as a lexical-function-name. Pro- 
cessing continues until the last lexeme of a valid lexical-function has been 
processed. When processing is complete, the lexical-function is replaced by a 
sequence of lexemes that is its expansion. 

The processing of a lexical-function can be prevented by placing %QUOTE in 
front of it. 

When processing of a lexical-function is complete and the lexical-function has 
been replaced by its expansion, the compiler takes its next lexeme from the 
beginning of the expansion. If the expansion is the empty sequence, the com- 
piler takes its next lexeme from the stream that follows the lexical-function. 

Most lexical-functions require a parenthesized list of actual-parameters. That 
parameter list can, itself, contain lexical-functions or macro-calls; it is no 
different in that respect than other portions of a BLISS module. 

Each actual-parameter of a lexical-function is processed at either name-quote 
level or normal-quote level. For example, the first two actual-parameters of 
the %EXACTSTRING function are at normal-quote level, while the remain- 
ing actual-parameters are at name-quote level. In the individual definitions in 
Section 15.5, this distinction is indicated by placing a § character before each 
parameter that is processed at name-quote level. 

Once the actual-parameters have been processed, they must satisfy certain 
restrictions. The definition of each lexical-function gives restrictions that ap- 
ply to its parameters. But one restriction applies to all lexical-functions: when 
a parameter can be an expression, it must be a compile-time-constant-expres- 
sion. This restriction is necessary because lexical-functions" are always ex- 
panded during compilation. 

A few lexical-functions cause the compiler to skip over a lexeme sequence that 
could otherwise be compiled. For example, %ERRORMACRO will, under 
certain circumstances, abort every macro-call expansion that is in progress. 
However, such lexical-functions never cause a portion of the unparsed input 
stream to be skipped; instead, they discard secondary sources of lexemes 
(macro-bodies) and proceed as if each of those macro-bodies had ended. Such 
lexical-functions are defined in Section 15.5.11 (%ERRORMACRO) and Sec- 
tion 15.5.14 (%EXITITERATION and %EXITMACRO). 
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15.5 Specific Lexical-Functions 

For purposes of this presentation, the lexical-functions are grouped as follows: 

String-Functions %STRING, %EXACTSTRING, %CHAR, 

%CHARCOUNT 
Delimiter-Functions %EXPLODE, %REMOVE 

Name-Function %NAME 

Sequence-Test-Functions %NULL, %IDENTICAL 
Expression-Test-Functions %ISSTRING, %CTCE, %LTCE 
Bits-Functions %NBITSU, %NBITS 

Allocation-Functions %ALLOCATION, %SIZE 

Fieldexpand-Function %FIELDEXPAND 

Calculation-Functions %ASSIGN, %NUMBER 

Compiler-State-Functions %DECLARED, %SWITCHES, %BLISS, 

%VARIANT 
Advisory-Functions %ERROR, %WARN, %INFORM, 

%PRINT, %MESSAGE, %ERRORMACRO 
Title-Functions %TITLE, %SBTTL 

Quote-Functions %QUOTE, %UNQUOTE, %EXPAND 

Macro-Functions %REMAINING, %LENGTH, %COUNT, 

%EXITITERATION, %EXITMACRO 
Require-Function %REQUIRE 

A description of these lexical-functions follows. The description begins with a 
brief discussion of quotation within lexical-functions. Then each class of lexi- 
cal functions is described in its own section. Finally, all the lexical-functions 
are summarized in a single table. 

15.5.1 Quote Levels for Lexical-Actual-Parameters 

If a lexical-function appears in a context that is at macro-quote level, then the 
lexical-function is not expanded and its parameters are processed at macro- 
quote level. Otherwise, each parameter is processed at a quote level that is 
specified in the definition of the lexical-function. 

In the definitions of lexical-functions that follow, a § character sometimes 
appears before a parameter; in that case, the parameter is processed at name- 
quote level and is called a "name-quote parameter". Otherwise, the parame- 
ter is processed at normal-quote level. 

For example, the definition of %EXACTSTRING in Section 15.5.2 begins 
with 

%EXACTSTRING( n , fill , #p ,... ) 
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Therefore, the first two parameters of ( ( EXACTSTRING are processed at 
normal-quote level and the remaining parameters are processed at name- 
quote level. 

Note that the character ft is part of the definition of BLISS; it never actually 
appears before a parameter in a program. 

15.5.2 String-Functions 

The string-functions operate on or produce quoted-string lexemes. They are 
important because they facilitate the compile-time manipulation of quoted- 
strings, and provide a useful basis for the definition of new macros by the 
programmer. The string-functions also support the run-time functions for 
character handling that are described in Chapter 20. 

Most of these functions convert a given sequence of lexemes into a different 
but essentially equivalent sequence of lexemes. The ( < STRING function con- 
verts a sequence of lexemes into a single quoted-string lexeme. The ^EX- 
ACTSTRING function is like c 'r STRING except that it adjusts the resulting 
quoted-string to a specified length. The f rCHAR function takes a sequence of 
numeric values and converts it into a quoted-string lexeme. 

The only string-function that does not perform a lexical conversion (as infor- 
mally defined in the preceding paragraph) is f rCHARCOUNT. This function 
forms a quoted-string and then yields a numeric-literal equal to the number of 
quoted-characters in the string. 

The c c STRING function plays a leading role among the lexical-functions be- 
cause several lexical-functions are based on it. It accepts parameters that are 
each a quoted-string, numeric-literal, name, or empty sequence, and it puts 
these parameters together into a single quoted-string lexeme. Examples are. 

Function Expansion 

'/STRING* 'ABC ' » 'D ' ) 'ABCD' 

■/.STRING (23 >1Q '-1 1 1 ' ) '23-7' 

7,STRING( ALPHA ,, ,9) 'ALPHA9' 

The following lexical functions are all based on the c 7 STRING function: 

String-Functions ^EXACTSTRING, RCHARCOUNT 

Delimiter-Function ^EXPLODE 

Name-Function %NAME 

Advisory-Functions TERROR, RWARN, c c INFORM, SPRINT, 

^MESSAGE, RERRORMACRO 
Require-Function %REQUIRE 

Each of these lexical-functions begins by using the r r STRING function to 
gather its parameters into a single quoted-string. Then the function performs 
an action on the quoted-string that is different for each function. 
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15.5.2.1 Definition — The string-functions are expanded as follows: 
^STRING* #p ,... ) 

Restriction. Each parameter must be one of the following: 

Fullword numeric-literal, that is: 

unsigned decimal-literal 

integer-literal 

character-code-literal 
ASCII string-literal, that is: 

quoted-string 

%ASCII string-literal 

%ASCIZ string-literal 

%ASCIC string-literal 
Identifier except for reserved keyword 
Empty sequence 

Expansion. Modify each parameter, depending on what kind of lexeme it 
is, as follows: 



• 



• 



If the parameter is a quoted-string, then remove the initial and final 
quote characters. 

If the parameter is a string-literal with a string-type, then process the 
string-type (Section 4.3), adding a leading or trailing character position 
as required, and remove the initial and final quote characters. 

If the parameter is a numeric-literal, then represent its value as a 
standard numeric-literal. A standard numeric-literal represents a posi- 
tive value as a sequence of decimal digits that does not begin with 0, 
and represents a negative value as a minus sign followed by a sequence 
of digits that does not begin with 0. 

• If the parameter is a name, change any lower-case letters to upper- 
case. 

• If the parameter is an empty sequence, leave it as is. 

Concatenate the modified parameters in the order given to form a single 
character sequence. Place the sequence in quotes, forming a quoted- 
string. Return the quoted-string. 

%EXACTSTRING( n , fill , #p ,... ) 
%EXACTSTRING( n , fill ) 

Restrictions. The parameter n must be a compile-time-constant-expres- 
sion, and its value must satisfy implementation restrictions, given else- 
where, on the length of a character sequence. 

The parameter fill must be a compile-time-constant-expression, and its 
value must be in the range through 255. (Use of a simple string-literal 
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to represent a fill character is strongly discouraged since it will produce 
differing results in different dialects; see Section 3.3. Use of the charac- 
ter-code-literal — %C'character' — however, is fully transportable.) 

Each of the remaining parameters must satisfy the restrictions on 
f r STRING parameters. 

Expansion. Evaluate the first two parameters. Then proceed as for the 
%STRING function, obtaining a single quoted-string from the third 
through last actual-parameters. If the function has only two parameters, 
form the empty quoted string, ". 

Modify the resulting quoted-string as follows: 

• If the quoted-string represents n characters, leave it unchanged. 

• If the quoted-string represents more than n characters, remove quoted- 
characters from the right end until it represents n characters. 

• If the quoted-string represents less than n characters, add quoted- 
characters at the right end until it represents n characters. Use the 
character whose ASCII code is given by the value of fill. 

Return the resulting quoted-string. 

%CHAR( code ,... ) 

Restrictions. Each parameter must be a compile-time-constant-expres- 
sion. The value of each parameter must be in the range through 255. | 

Expansion. Evaluate each parameter and interpret its value as the code 
for an ASCII character. Concatenate the resulting characters to form a 
single character sequence. Return the quoted-string that represents that 
character sequence. 

%CHARCOUNT( #p ,... ) 

Restriction. The parameters must satisfy the restrictions on %STRING 
parameters. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Determine the number of quoted-characters (see Section 
4.3.1) in the quoted-string. Represent this number as a numeric-literal. 
Return the numeric-literal. 

The result of a %STRING, %EXACTSTRING, or %CHAR function is a 
quoted-string. However, unlike the quoted-strings written by BLISS pro- 
grammers, this quoted-string is not restricted to printing characters, blanks, 
and tabs; instead, it can represent any sequence of ASCII characters. This 
quoted-string is processed by the compiler as if it were an ordinary quoted- 
string. 
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15.5.2.2 Examples — The examples that follow are designed to illustrate the 
definition of the various string-functions, not to show how they should be 
used. Thus they are simple and, in some cases, unrealistic. 

Examples of the %STRING function are: 
Function Expansion 

'/.STRING* 'ABC ' ) 'ABC 

"/.STRING* 'ABC ' , 'D ' ) 'ABCD' 

ZSTRINGCZ.C 'A ' ) '65' 

'/STRING* 'ABC ' tlC 'A ' ) 'ABC65' 

ZSTRING(23) '23' 

/STRING (00023) '23' 

/STRING* '00023 ' ) '00023' 

/string (20+3) (INVALID: Operator not allowed) 

ZSTRING( '20 + 3 ' ) '20+3' 

ZSTRINGCZB '-1 1 1 1 ' ) '-15' 

/STRING (7,0 '77 ' »'/)•( '77 ' ) '63119' 

/string ( ze ' l , 125E- 02 ' ) (INVALID: Float-literal not allowed) 

/STRING( beta , 'beta ' ) 'BETAbeta' 
ZSTRING( ,X t ,Y) 'XY' 

z st ring<onn, module) (INVALID : Reserved-key words not 

allowed) 

ZSTRING( 'OWN' » 'MODULE ' ) 'OWNMODULE' 

ZSTRING(0 ,18) 'Q18' 

ZSTRING(0 ,/DECIMAL '-IS ' ) 'Q-18' 

zstring(0,-18) (INVALID: Leading sign not allowed) 

It is assumed in these examples that beta, X, Y, and Q are not macro-names. 
As %STRING parameters, non-macro names are treated literally (except for 
possible case conversion), whereas a macro-name is expanded. 

In most programming situations* at least some of the parameters of the 
%STRING function (or any other lexical-function) are variable. Consider, for 
example: 

ZSTRING(L) »'='»y(X»Y)) 

Assume that U and V are declared as macros. The %STRING function will 
put the expansions of the two macros into a single quoted-string separated by 
an '=' sign. If the expansions of U and V are 'ALPHA' and 'X+Y', respec- 
tively, then the final expansion of the %STRING function is the quoted-string 
'ALPHA=X+Y'. 
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Examples of the %EXACTSTRING function are: 



Function 




Expansion 


%EXACTSTRING(G tlC 'X' » 


'ABC ' ) 


'ABCXXX' 


"JGEXACTSTRINGO tlC'X' t 


'ABC ' ) 


'ABC 


XEXACTSTRING(2 tlC ')<' t 


'ABC ) 


<AB' 


%EXACTSTRING(0 tlC ')■(' t 


'ABC ' ) 


<» 


%EXACTSTRING(-2 tlC'X' 


t 'ABC ' ) 


(INVALID: 



'ZEXACTSTRING(4 tlC ' - ' ) 
/f,EXACTSTRING<6 f'JGC '* ' >38 

XEXACTSTRINGU tlC ' 
%EXACTSTRING(4 , ' \" 
XEXACTSTRING(4 » 'Y' 
Z.EXACTSTRING<4 tlC'\ 
7,EXACTSTRING(4 ,83 



G') '38-6**' 



Y' tlC 'X ' ) 


'88YY' 


t ' X ' ) 


'X' in BLISS-36 only! 


t r\ > 


'XYYY' in BLISS-16/32 only! 


Y ' » ' X ' ) 


'XYYY' in all dialects 


' X ' ) 


'XYYY' 



Examples of the %CHAR function follow. They are assumed to lie in the scope 
of these declarations: 



LITERAL 

ACODE = (35 t 
BCODE = BG t 
APOSTROPHE = 39 » 
CR = 13 t 
LF = 10 5 



The examples are: 
Function 



7,CHAR(G5 »GG) 

7,CHAR( ACODE >BC0DE) 

7,CHAR(AC0DE + 32) 

7,CHAR(AC0DE ^APOSTROPHE »BC0DE> 

ICHAR(CR tLF) 



Expansion 

'AB' 
'AB' 

'a' 

'A"B' (3 characters) 

(new line) 



Examples of the %CHARCOUNT function are: 
Function Expansion 



7,CHARC0UNT< 'ABC ' ) 
/CCHARCOUNT* » t ' ' t ) 
7,CHARC0UNT( 'A ' 'C ' ) 



15.5.3 Delimiter-Functions 

The delimiter-functions insert or delete delimiters within a given string. 
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The %EXPLODE function forms a quoted-string and then "explodes" it into 
a list of single-character quoted-strings. It can be used to take a given string 
apart. The %REMOVE function deletes parentheses, brackets, or angle 
brackets that enclose a given actual-parameter. 

15.5.3.1 Definition — The delimiter-functions are expanded as follows: 

%EXPLODE( #p ,... ) 

Restriction. Each parameter must satisfy the restriction on %STRING 
parameters. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. 

Remove the quotes from the ends of the resulting quoted-string, place 
each quoted-character in its own pair of quotes, and insert a comma 
between each quoted-string and the next. 

Return the resulting sequence of quoted-strings and commas. 

%REMOVE( #p ) 

Expansion. If the parameter begins and ends with a matched pair of 
parentheses, (...), brackets, [...], or angle brackets, <...>, then remove 
these lexemes from the parameter. Otherwise, leave the parameter un- 
changed. 

Return the resulting sequence of lexemes. 

The result of a %EXPLODE function is a sequence of one or more one- 
character quoted-strings. As with the %STRING, %EXACTSTRING, and 
%CHAR lexical-functions, these quoted-strings can represent any ASCII char- 
acters. 

15.5.3.2 Examples — Examples of the 96EXPLODE function are: 



Function 




Expansion 




/EXPLODE* 'ABC ' ) 




'A','B7C' 


(5 lexemes) 


/EXPLODE* 'A ' ) 




'A' 


(1 lexeme) 


/EXPLODE* ) 




<> 


(1 lexeme) 


/EXPLODE* 'A ' » 'B ' 


) 


'A','B' 


(3 lexemes) 


'/.EXPLODE */0 '11 ' ) 




'673' 


(3 lexemes) 


'/EXPLODE* 'A ' ,7,0' 


-77 ' 


) 'A7-7673' 


(7 lexemes) 



The following example is especially interesting: 

'/.STRING* '/EXPLODE ( 'ABC ' ) ) 
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In this example, %STRING acts as the inverse of %EXPLODE, and the final 
expansion of the nested functions is just 'ABC. 

Examples of the %REMOVE function follow. 



Function 


Expansion 


'/■REMOVE ( (A fB »C) ) 


A, B, C 


'/.REMOVE (<A+1 >) 


A+l 


'/REMOVE ( CR( A+l ) ] ) 


R(A+1) 


/REMOVE ( (A+B) ) 


A+B 


/REMOVE ( (A)+(B) ) 


(A)+(B) 



This function is usually applied to macro-formal-names. A simple example of 
this application is: 



MACRO 

A ( X ) = RRR ( /REMOVE ( X ) ) + I '* 5 

A( 1 ) ; 

A( ( 1 »2 #3) ) ; 



The extra parentheses in the second macro-call are required to keep its pa- 
rameter from being treated as three parameters. The %REMOVE function 
deletes the extra parentheses, and the two macro-calls expand to: 

RRR( 1 ) + l ; 
RRR( 1 »2 t3) + l i 

Assuming that RRR is a conditional or iterative macro (as defined in Section 
16.3) and thus accepts a parameter list of variable length, this is a useful 
result. 

15.5.4 Name-Functions 

Sometimes it is necessary to put together a name during program compila- 
tion. This need arises either because the name cannot be written (conven- 
iently) in advance or because it is a sequence of characters that would not 
normally be accepted as a name. 

15.5.4.1 Definition — The name-functions are expanded as follows: I 

%NAME( #p ,... ) 

%QUOTENAME ( #p ,... ) | 

Restriction. Each parameter must satisfy the restriction on %STRING 
parameters. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. 

Treat the sequence of quoted-characters in the quoted-string as a name. 
Return the resulting name. 
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The result of a %NAME and %QUOTENAME lexical-function is a name. 
Unlike the names written by BLISS programmers, this name is not restricted 
to the syntax for a BLISS name; instead, it can be any sequence of ASCII 
characters. It is accepted by the compiler as a name. 

The %QUOTENAME lexical-function is similar to the %NAME function, the 
exception being that the resultant name is implicitly %QUOTED to prevent 
macro-expansion of the name. 

15.5.4.2 Examples — The %NAME function permits the formation of a name 
out of parts that are compile-time variables. An example is: 

MACRO 

BLOCKOP(A) = 

OWN A: BLOCKC 10] i 

ROUTINE ZNAME( A ,"_INIT ' ) : N00ALUE = 
BEGIN 

end; 
i ; 

Suppose this macro is called as follows: 

BLOCKOP(BETA) 

The expansion is: 

OWN BETA: BLOCKC 10] 5 
ROUTINE BETA.INIT: NOOALUE = 
BEGIN 

END ; 

The macro BLOCKOP uses the given name, BETA, for an OWN data seg- 
ment. It uses %NAME to generate a related but distinct name, BETA INIT, 

for the routine that initializes BETA. 

The %NAME function also can be used to force the compiler to accept any 
character sequence as a name. That can be useful when something entirely 
new is needed. An example is: 

ZNAME( '+302 ' ) 

Each time this construct appears, it is equivalent to writing just +302 and 
having those four characters accepted by the compiler as a valid name. 

The %NAME function should not be used casually. Sometimes its use can 
cause an unexpected conflict with names generated by the compiler. For 
example, one compiler uses names like P. AAA, P.AAB, and so on, for plit 
storage. Furthermore, some operating systems restrict global names to the 
characters that are in the RAD50 character set; in that situation, 
%NAME(+302) would be invalid as a global name. 

The %NAME function cannot be used to produce the "name" of a macro that 
is already declared; it will, however, always produce the macro expansion and 
may be used to invoke and expand a legitimately produced macro, as follows: 

MACRO 7,NAME( 'A.B' ) = OWN X ! % i 

XNAME('A.B') (expands to "OWN X?" 
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There are also cases in which f V'NAME is essential. For example, the period 
character is used for global names in some software. Since period cannot be 
used in an ordinary BLISS name, f V NAME must be used to form such a 
global name. 

As an example of the use of the r ,7QU0TENAME function, consider the 
following: 

MACRO FOOBAR = .XYZ * 5 1 i ' 
UNDECLARE XNAME ( ' F00 ' » 'BAR ' ) 5 

This would produce an error, because the compiler would interpret the UN- 
DECLARE declaration as: 

UNDECLARE .XYZ * 5 

Moreover, inserting a %QUOTE before the c < NAME would again result in an 
incorrect compiler interpretation of: 

UNDECLARE '/.QUOTE XNAME ( ' F00 ' » ' BAR ' ) 

However, using the %QUOTENAME function as follows: 

UNDECLARE XQUOTENAMEt 'F00 » 'BAR ' ) 

results in a correct expansion to the following equivalent: 

UNDECLARE ZOUOTE FOOBAR i 
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15.5.5 Sequence-Test-Functions 

A sequence-test-function expands to 1 or 0, depending on whether or not a 
certain condition is met. Since a test-function is expanded during compila- 
tion, it can be used within other lexical constructs. In particular, a sequence- 
test-function can be used as a compile-time-test in a lexical-conditional, as 
described in Section 15.6. 

The two test-functions, %NULL and %IDENTICAL, are applied to lexeme 
sequences. The %NULL function determines whether a sequence is empty; 
that is, contains nothing. The %IDENTICAL function compares two 
sequences to determine if they contain the same lexemes in the same order. 

15.5.5.1 Definition — The sequence-test-functions are expanded as follows: 

%NULL( #seq ,... ) 

Expansion. Process the actual-parameters as for an ordinary macro-call, 
as defined in Section 16.3.3.1. Return the numeric-literal 1 or 0, depend- 
ing on whether or not all the parameters expand to the empty sequence. 

%IDENTICAL( #seql , #seq2 ) 

Expansion. Process the actual-parameters, seql and seq2, as for an ordi- 
nary macro-call, as defined in Section 16.3.3.1. Return the numeric-lit- 
eral 1 or 0, depending on whether or not the two resulting lexeme 
sequences are the same. 

When two identifiers are compared, all letters are considered to be upper- 
case, so that case is effectively ignored. When two numeric-literals are 
compared, the numeric values of the numeric-literals are compared 
rather than the numeric-literals themselves. 

15.5.5.2 Examples — Examples of the %NULL and %IDENTICAL functions 
are: 

Function Expansion 

7,NULL() 1 

7.NULL* tt) 1 

7,NULL(XEXACTSTRING*0 »0 » 'ABC ) ) 

7NULL* tALPHA) 

7,IDENTICAL(A + B ,A + B> 1 

7 IDENTICAL* » ) 1 

7, IDENTICAL (3 1 7.CHARC0UNT ( 'ABC ' ) ) 1 

7IDENTICAL*70 '77 ' »B3) 1 

EIDENTICAUALPHA »alpha) 1 

/£ IDENTICAL* 'ALPHA' > 'alpha ' ) 

'Jf. IDENTICAL* A + B »A + C) 

7. IDENTICAL* 32 t '32' ) 
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The third example of %NULL is interesting, since it might be thought that a 
character sequence of length would be a lexical sequence of length 0. How- 
ever, the value of 

KEXACTSTRINGtO »0 > 'ABC ) 

is the string-literal that represents the empty character sequence, ", and that 
string-literal constitutes one lexeme. 

15.5.6 Expression-Test-Functions 

An expression-test-function expands to 1 or 0, depending on whether or not 
each of its parameters constitute a particular form of expression. Since a test- 
function is expanded during compilation, it can be used within other lexical 
constructs. In particular, an expression-test-function can be used as a com- 
pile-time-test in a lexical-conditional, as described in Section 15.6. 

The functions %ISSTRING, %CTCE, and %LTCE are applied to expressions. 
The %ISSTRING function determines whether or not each of its parameters is 
a string-literal. The %CTCE function determines whether or not each of its 
parameters is a compile-time-constant-expression. The %LTCE function de- 
termines whether or not each of its parameters is a link-time-constant-expres- 
sion. 

15.5.6.1 Definition — The expression-test-functions are expanded as follows: 

%ISSTRING( exp ,... ) 

Restriction. Each parameter must be a valid expression. 

Expansion. Process each parameter, expanding all macro-calls and lexi- 
cal-functions. Return the numeric-literal 1 if each of the resulting expres- 
sions is a quoted-string; return the numeric-literal if any of the result- 
ing expressions is not a quoted-string. 

%CTCE( exp ,... ) 

Restriction. Each parameter must be a valid expression. 

Expansion. Process each parameter, expanding all macro-calls and lexi- 
cal-functions. Return the numeric-literal 1 if each of the resulting expres- 
sions is a compile-time-constant-expression; return the numeric-literal 
if any of the resulting expressions is not a compile-time-constant-expres- 
sion. 

%LTCE( exp ,... ) 

Restriction. Each parameter must be a valid expression. 

Expansion. Process each parameter, expanding all macro-calls and lexi- 
cal-functions. Return the numeric-literal 1 if each of the resulting expres- 
sions is a link-time-constant-expression; return the numeric-literal if 
any of the resulting expressions is not a link-time-constant-expression. 
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15.5.6.2 Examples — Examples of the expression- test-functions are: 
Function Expansion 

%ISSTRING< 'ALPHA' » 'BETA' > 'GAMMA' > 1 

'JGISSTRINGt 'ALPHA' , 'BETA' t GAMMA) 

/assTRiNGCKASCic 'alpha') 1 <= 16/32 Only 

7,ISSTRING(XRAD50„H 'AB.99' ,XP'372' ) 1 <= 16/32 Only 

3;iSSTRING(GET_STRING_RTN(BUF+I ) ) 

ZISSTRINGCKCHARCOUNTt 'GAMMA' ) ) 

IKISSTRINGCKSTRINGCfcASCIC'BETA' ) ) 1 

XISSTRING( 'ABCDEFGHIJ ' ) 1 

5f.ISSTRING(PLIT( 'ABCDEFGHIJ' ) ) 

(Context for the following examples: 

ONN Xs REF VECTOR t 
Y: VECTOR [10 3 5 
EXTERNAL LITERAL A 5 
LITERAL V = 100! ) 

Z.CTCE (X»Y) 

'JGCTCE (A) 

1CJCE (U) 1 

KCTCE (AtM) 

1LTCE <X>Y) 1 

3CLTCE (X + A) 1 

'ZLTCE (XCO]) 

ZLTCE (YC93) 1 

7.LTCE <V) 1 

15.5.7 Bits-Functions 

A bits-function determines the smallest number of bits required for the BLISS 
encoding of a given value. The %NBITSU function determines the number of 
bits required for an unsigned encoding, and the %NBITS function does the 
same for a signed encoding. 

15.5.7.1 Definition — The bits-functions are expanded as follows: 

%NBITSU( n ,... ) 

Restriction. Each parameter must be a compile-time-constant-expres- 
sion. 

Expansion. This function calculates a bit count for each of its parame- 
ters. The bit count is the smallest number of bits required to represent 
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the parameter as an unsigned binary integer. The following algorithm is 
used: 

• If the function has just one parameter, evaluate that parameter. 

- If the value of the parameter is negative, then the desired bit count 
is %BPVAL (which, in BLISS-32 for example, is 32). 

- Otherwise, the desired bit count is the smallest integer, i, that satis- 
fies the following relation: 

< vp < (2**i)-l 

where vp is the value of the given parameter, and 2**i means "2 to 
the i'th power". 

• If the given %NBITSU function has several parameters, then the de- 
sired bit count is the value of the following expression: 

MAX( %NBITSU( nl ), %NBITSU( n2 ),... ) 

where nl, n2, and so on, are the given parameters. 

Represent the bit count thus obtained as a numeric-literal. Return the 
numeric-literal. 

%NBITS( n ,... ) 

Restriction. Each parameter must be a compile-time-constant-expres- 
sion. 

Expansion. This function calculates a bit count for each of its parame- 
ters. The bit count is the smallest number of bits required to represent 
the parameter as a signed (two's complement) binary integer. The follow- 
ing algorithm is used: 

• If the function has just one parameter, evaluate that parameter. The 
desired bit count is the smallest integer, i, that satisfies the following 
relation: 

-(2**(i-l)) < vp < (2**(i-l))-l 

where vp is the value of the given parameter and 2**(i-l) means "2 to 
the (i-l)'th power". 

• If the given %NBITS function has several parameters, then the desired 
bit count is the value of the following expression: 

MAX( %NBITS( nl ), %NBITS( n2 ),... ) 

where nl, n2, and so on, are the given parameters. 

Represent the bit count thus obtained as a numeric-literal. Return the 
numeric-literal. 
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15.5.7.2 Examples — Examples of the %NBITSU and %NBITS functions 
are: 

Expansion of Expansion of 

Parameter List %NBITSU %NBITS 

-8 %BPVAL 4 

-1 %BPVAL 1 

1 

1 1 2 

2 2 3 
255 8 9 

1,7 3 4 

-8,7 %BPVAL 4 

0,1,255,2,3 8 9 

15.5.8 Allocation-Functions 

An allocation-function determines the amount of storage required for a given 
kind of data. Allocation-functions are useful in laying out storage and calcu- 
lating address offsets. 

The %ALLOCATION function determines how many addressible units have 
been allocated for a given data name. The %SIZE function determines how 
many addressible units would be allocated for a given structure-attribute if 
that attribute were used in a data declaration. 

15.5.8.1 Definition — The allocation-functions are expanded as follows: 

%ALLOCATION( name ) 

Restriction. The parameter must be a name that is declared as one of the 
following: 

OWN 

GLOBAL 

FORWARD 

LOCAL 

STACKLOCAL 

REGISTER 

GLOBAL REGISTER 

EXTERNAL REGISTER 

Expansion. Determine the number of addressible units allocated in the 
data segment for the given name. Represent the number just obtained as 
a numeric-literal. Return the numeric-literal. 

%SIZE( structure-attribute ) 

Restriction. The parameter must be a structure-attribute, as described in 
Chapter 11. 
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Expansion. Determine the number of addressible units that would be 
allocated for a data structure if the given structure-attribute appeared in 
a data-declaration at this point in the program. (A full description of 
structure-attributes is given in Section 11.4.) Represent the number just 
obtained as a numeric-literal. Return the numeric-literal. 

15.5.8.2 Examples — The examples that follow are assumed to lie in the 
scope of these declarations: 

GLOBAL 

A » 

Y: BYTE i <= BLISS- 16/32 only 

Z: VECTOR C 10] 5 
STRUCTURE 

ARRAYC I »J !M »N] = 

[M*N*43 

(ARRAY+( I*N+J)*4) 5 

Examples of the % ALLOCATION and %SIZE functions are: 

Function Expansion 

zallocationoo %UPVAL (for example, 1 in 

BLISS-36) 
xallocation(Y) 1 (in BLISS-16/32 only) 

zallocation(Z) %UPVAL*10 (for example, 40 in 

BLISS-16)) 

7,size(0ECT0RC10] ) %UPVAL*10 (for example, 20 in 

BLISS-16) 

i s i z E < o e c t a r c l o » w o R d ] ) 20 (in BLISS-16/32 only) 

7,size(REF vector) %UPVAL (for example, 1 in 

BLISS-36) 

zsize(ARRAYC3 ,3] ) %UPVAL*9 (for example, 36 in 

BLISS-32) 

15.5.9 Fieldexpand-Function 

The fieldexpand-function plays a specialized role in the declaration of data- 
structures. The function is used in conjunction with field-names, which are 
described in Chapter 11. 

The %FIELDEXPAND function replaces a given field-name with its associ- 
ated list of field-components. When an additional parameter is given, that 
parameter selects one of the field-components. 

15.5.9.1 Definition — The field-functions are defined as follows: 

%FIELDEXPAND( field ) 
%FIELDEXPAND( field , n ) 

Restrictions. The first parameter must be a field-name declared in a 
field-declaration. 
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The second parameter, if present, must be a compile-time-constant-ex- 
pression, and its value, v, must lie in the range through k-1, where k is 
the number of field-components associated with field. 

Expansion. Determine the list of field-components associated with the 
given field-name (see Chapter 11). 

Represent each field-component as a standard numeric-literal (see the 
definition of %STRING); use a comma to separate each field-component 
in the list from the next. 

If a second parameter is not given, return the entire list of field-compo- 
nents. Otherwise, return the u-th field-component, where v is the value of 
the second parameter. 

15.5.9.2 Examples — The examples that follow are assumed to lie in the 
scope of this declaration: 

FIELD 

DCB_FIELDS = 
SET 

DCB„A = CO fO »0 »0] t 
DCB_B = CO »8 »3 »03 » 
DCB„C = CO »1 1 ,5 ill f 
DCB-D = CO»lB»lBfl]f 
DCB„E = CI ,0 »'Jf.BPVAL »0] 
TES 5 

(This declaration is taken from Chapter 12, where field-declarations are de- 
scribed and illustrated.) 

Examples of the %FIELDEXPAND function are: 

Function Expansion 

xfieldexpand(Dcb_A) 0,0,0,0 (7 lexemes) 

?.fieldexpand(DCB_C) 0,11,5,1 (7 lexemes) 

>KFiELDEXPAND(DCB_CfO) (1 lexeme) 

5T.FIELDEXPAND(DCB_C »3) 1 (1 lexeme) 

A field-name in a structure-reference is expanded without application of the 
%FIELDEXPAND function. Elsewhere, the %FIELDEXPAND function is 
necessary to force expansion. 

15.5.10 Calculation-Functions 

The calculation-functions provide a compile-time facility for calculating a 
value, saving it, and using it later in the compilation. 

The %ASSIGN function assigns a value during program compilation. The 
value is obtained from a compile-time-constant-expression and is assigned to 
a COMPILETIME name. The %NUMBER function produces a numeric- 
literal from another numeric-literal, a quoted-string, or a name. When the 
%NUMBER function is applied to a name, the name must be a COMPILE- 
TIME, LITERAL, or GLOBAL LITERAL name. 
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15.5.10.1 Definition — The calculation-functions are expanded as follows: 

%ASSIGN( fname , n ) 

Restrictions. The first parameter must be a name that is declared COM- 
PILETIME. 

The second parameter must be a compile-time-constant-expression. 

Expansion. Evaluate the second parameter and associate the resulting 
value with the first parameter. Return the empty sequence. 

%NUMBER( p ) 

Restrictions. The parameter must be a quoted-string, a numeric-literal, 
or a name. 

If the parameter is a quoted-string, its quoted-characters must consist of 
an optional sign followed by a sequence of decimal digits. If the parame- 
ter is a numeric-literal, it must not be a float-literal. If the parameter is a 
name, it must be declared as one of the following: 

LITERAL 

GLOBAL LITERAL 
COMPILETIME 

Expansion. First determine the value of the parameter, as follows: 

• If the parameter is a quoted-string, then remove the quotes and inter- 
pret the remainder as a decimal integer. 

• If the parameter is a numeric- literal, use the value it represents. 

• If the value is a name, use the value associated with the name by its 
declaration or, in the case of a COMPILETIME name, the most re- 
cently processed %ASSIGN function. 

Once the value of the parameter has been determined, represent that 
value as a numeric-literal. Return the numeric-literal. 

15.5.10.2 Example — An example of a macro that uses the %ASSIGN func- 
tion appears in the following program fragment: 

BEGIN 

♦ ♦ ♦ 

COMPILETIME 

errs = o; 

MACRO 

COUNT-ERROR = 7.ASS I GN ( ERRS »ERRS+ 1 ) li 

END 

The first declaration in this block declares ERRS as a COMPILETIME name. 
The second declaration declares COUNT ERROR as a macro name. Wher- 
ever COUNT—ERROR is called, it will expand to: 

'ZASSIGN< ERRS » ERRS+1 ) 

Wherever the compiler encounters this expansion, it will increase ERRS by 
one. Thus the macro can be used to keep a count of a particular kind of error. 
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The combined use of the % AS SIGN and %NUMBER function is the only way 
the value of a compile-time-constant-expression can be incorporated in a 
compile-time character sequence. An example is: 

COMPILETIME 

N = Ot 

q = a; 

XASSIGNtN »2*Q-1 ) 

XINF0RM( "HERE IS AN INTEGERS ' ^NUMBER ( N ) ) 

The use of %ASSIGN is essential because 2*Q-1 is not a valid parameter for 
either %INFORM or %NUMBER. 

More examples of the %NUMBER function follow. They are assumed to lie in 
the scope of the following declaration: 

LITERAL 

= -16 ; 

The examples are: 

Function Expansion 

^number ( '-180' ) -180 (coded internally as one lexeme) 

%NUMBER(83) 83 

XNUMBERC/f.O' 100 ' ) 64 

^number(Q) -16 (coded internally as one lexeme) 

15.5.11 Compiler-State-Functions 

Like the sequence-test-functions, a compiler-state-function expands to or 1, 
depending on whether or not a certain condition is met. Since the function is 
expanded during compilation, it can be used within other lexical constructs. 
In particular, a compiler-state-function can be used as a lexical-test in a 
lexical-conditional, described in Section 15.6. 

The compiler-state-functions refer to tables that are maintained by the com- 
piler. The %DECLARED function determines whether a given name has been 
explicitly declared. The %SWITCHES function determines the settings of one 
or more compilation switches. The %BLISS function determines which com- 
piler (BLISS-16, BLISS-32, or BLISS-36) is in use. The %VARIANT func- 
tion determines the integer value given in the /VARIANT qualifier switch (if 
any) in the compiler command line. 

15.5.11.1 Definitions — The test-functions are expanded as follows: 

%DECLARED( fname ) 

Restriction. The parameter must be a name. 

Expansion. Return the numeric-literal 1 or 0, depending on whether or 
not it is explicitly declared at this point in the compilation of the pro- 
gram. 
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%SWITCHES( #switch-name ,... ) 

Restriction. Each parameter must be one of the following on-off- 
switches: 

ERRS I NOERRS 
OPTIMIZE I NOOPTIMIZE 
UNAMES I NOUNAMES 
SAFE I NOSAFE 
ZIP I NOZIP 
CODE I NOCODE 
DEBUG I NODEBUG 

Expansion. Return the numeric-literal 1 or 0, depending on whether or 
not every parameter designates the current setting of an on-off-switch. 

%BLISS( #language-name ) 

Restriction. The parameter must be one of the following compiler names: 

BLISS16 
BLISS32 
BLISS36 

Expansion. Return the numeric-literal 1 or 0, depending on whether or 
not the parameter designates the compiler that is compiling this pro- 
gram. 

%VARIANT 

Expansion. One of the following must apply: 

• If the compiler command line contained a qualifier switch of the form: 

/VARIANTm or /VARIANT=n 
where n is an unsigned decimal-literal, then return n. 

• If the compiler command line contained a qualifier switch of the form: 

/VARIANT 
then return the decimal-literal 1. 

• If the compiler command line did not contain a /VARIANT qualifier 
switch, then return the decimal-literal 0. 

15.5.11.2 Examples — The examples that follow are assumed to lie in the 
scope of these, and only these, declarations: 

OWN 

A » 

B 5 
SWITCHES 

OPTIMIZE , 

NOCODE 5 
UNDECLARE B5 

It is further assumed that the compiler being used is a BLISS-32 compiler. 
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Examples of the %DECLARED, %SWITCHES, and %BLISS functions are: 
Function Expansion 

'/.DECLARED* A) 1 

XDECLARED(B) 

^DECLARED(C) 

%SWITCHES(OPTIMIZE) 1 

"JCSWITCHEStOPTIMIZE »N0C0DE) 1 

■Jf.SWITCHES<OPTIMIZE »C0DE) 

ZBLISS(BLISSIG) 

■«BLISS(BLISS32) 1 

IBLISS(BLISS3B) 

15.5.12 Advisory-Functions 

The advisory-functions generate compile-time output. The kind of advisory 
function determines the form of output: it may be an error message, a warning 
message, an informational message, or just a line in the program listing. 

Two of the advisory functions do more than generate compile-time output: 
%ERRORMACRO also aborts any current macro-expansion, and %ERROR 
inhibits most subsequent expression evaluations and causes the object module 
to be discarded. (See the appropriate BLISS User's Guide for further informa- 
tion on the side-effects of %ERROR.) 

15.5.12.1 Definitions — The advisory-functions are expanded as follows: 

%ERROR( #p ,... ) 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Use the quoted-string as the text of a compiler error mes- 
sage, transmit the message as if it were a standard diagnostic, and add 1 
to the compiler error count. Return the empty sequence. 

%WARN( #p ,... ) 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Use the quoted-string as the text of a compiler warning 
message, transmit the message as if it were a standard diagnostic, and 
add 1 to the compiler warning count. Return the empty sequence. 

%INFORM( #p ,... ) 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 
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Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Use the quoted-string as the text of a compiler information 
message, and transmit the message as if it were a standard diagnostic. 
(Do not increment either the compiler error or warning count.) Return 
the empty sequence. 

%PRINT( #p ,... ) - 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Insert the character sequence directly into the compilation 
listing as the next line of that listing. Return the empty sequence. 

%MESSAGE( #p ,... ) 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Write the character sequence directly to the user's termi- 
nal (or other standard output device for the compilation). Return the 
empty sequence. 

%ERRORMACRO( #p ,... ) 

Restriction. Parameters of an advisory-function must satisfy the restric- 
tion on parameters of the %STRING function. 

Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string. Use the quoted-string as the text of a compiler error mes- 
sage, transmit the message as if it were a standard diagnostic, and add 1 
to the compiler error count. Then, in addition, abort every macro-call 
expansion that is currently in progress. Resume compilation of the pro- 
gram with the lexeme that follows the outermost of the aborted macro- 
calls. 

15.5.12.2 Examples — Examples of the form of message produced by the 
advisory-functions appear in the BLISS User's Guides. 

15.5.13 Titling-Functions 

Each page of a compilation listing begins with a header. The header may vary 
from one implementation to another, but, typically, it includes the page num- 
ber, compilation date, and other identifying information. By means of the 
titling-functions, a programmer can specify a title and a subtitle for inclusion 
in the header. 

15.5.13.1 Definition — The titling-functions are expanded as follows: 

%TITLE qs 

Restriction. The lexeme qs must be a quoted-string. (Note that qs is not 
enclosed in parentheses.) 
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Expansion. Use the value of qs as the title in subsequent headers of the 
compilation listing. Return the empty sequence. 

%SBTTL qs 

Restriction. The lexeme qs must be a quoted-string. (Note that qs is not 
enclosed in parentheses.) 

Expansion. Use the value of qs as the subtitle in subsequent headers of 
the compilation listing. Return the empty sequence. 

These functions can be used repeatedly throughout a module, thus changing 
the title and/or subtitle from page to page of the listing. 

15.5.13.2 Examples — Listing titles and subtitles appear in the BLISS User's 
Guides. 



15.5.14 Quote-Functions 

The quotation-functions are used to override the quotation rules given earlier, 
in Section 15.2.2. Each function applies to the name or lexical-function-name 
that immediately follows it. The %QUOTE function can also be applied to a 
comma or percent lexeme. 

The %QUOTE function prevents a name from being bound and prevents 
expansion of a lexical-function or macro-call. The %UNQUOTE function 
causes a name to be bound but does not cause any expansion. The %EX- 
PAND function causes both binding and expansion. 

15.5.14.1 Definitions — The quote-functions are expanded as follows: 

%QUOTE 

Restrictions. The next lexeme must be a name, a lexical-function-name, 
a comma, or a percent sign. 

Use of this function is restricted to macro-bodies or to the actual-parame- 
ters of a macro-call or lexical-function. That is, it applies only to lexemes 
encountered at macro-quote or name-quote level. 

Expansion. Temporarily change the quotation rules so that binding of 
the next lexeme is deferred to a subsequent scan of the lexeme stream in 
which it occurs. More specifically, this means that: 

• If the next lexeme is an unbound name, an attempt to bind it will not 
occur when it is read. 

• If the next lexeme is the beginning of a macro-call or lexical-function, 
an attempt to expand the macro-call or lexical-function will not occur 
when it is read. 

• If the next lexeme is itself a quote-function in a macro-definition, that 
quote -function will be interpreted as a lexeme in the macro-body and 
thus will not, at that point, affect the binding of the lexeme which 
follows it. 
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• If the next lexeme is a comma in a list of actual-parameters in a 
lexical-function or macro-call, it will be interpreted as a lexeme in the 
current actual-parameter rather than as the separation between two 
actual-parameters. 

• If the next lexeme is a percent in a macro-definition, it will be inter- 
preted as a lexeme in the macro-body rather than as the termination of 
the macro-body. 

Return the empty sequence. 

%UNQUOTE 

Restriction. The next lexeme must be a name or lexical-function-name. 

Use of this function is restricted to macro-bodies or to the actual-parame- 
ters of a macro-call or lexical-function. That is, it applies only to lexemes 
encountered at macro-quote or name-quote level. 

Expansion. Attempt to bind the next lexeme. 

(Forced binding of a macro-name or lexical-function-name does not also 
force expansion of the corresponding call or function.) 

Return the empty sequence. 

%EXPAND 

Restriction. The sequence of lexemes that follow %EXPAND must begin 
with a lexical-function or macro-call. 

Use of this function is restricted to macro-bodies. That is, it applies only 
to lexemes encountered at macro-quote level. 

Expansion. Temporarily change the quotation rules so that the lexical- 
function or macro-call that follows %EXPAND is expanded. (Any macro- 
calls or lexical-functions contained in the expansion are not themselves 
automatically expanded.) 

Return the empty sequence. 

15.5.14.2 Examples — A simple example of the use of the %UNQUOTE 
function is given earlier (in Section 15.2). A series of more complex examples 
is given here. They are each based on the following program fragment: 

MACRO 

1 ( P ) = 1 , P It 

Q2 = 2 1 » 

X = 01(02) 7.5 

♦ ♦ ♦ 

ROUTINE R = 
BEGIN 
MACRO 

ZOUOTE 01 (X) = 10 >)< 1 t 

'/.QUOTE 02 = 20 "/..', 
BIND 

y = uplit( '/.string (x) ) 5 
end; 
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When Q1(Q2) in the declaration of X is processed, neither Ql nor Q2 is bound 
because they are names at macro-quote level (see Section 15.2.1). 

The %QUOTE functions are necessary in the second macro-declaration be- 
cause Ql and Q2 would otherwise be interpreted as macro-calls, and the 
declaration would become: 

MACRO 

1 > X = 1 > X 1 t 

2 = 20 % ; 

which is nonsense. This expansion would occur because Ql and Q2 are macro- 
names at name-quote level. 

A call on the macro X appears in the bind-declaration. When X is expanded 
and processed, it is 

10 »20 

This result reflects the fact that Ql and Q2 are both bound in the scope of the 
second declarations of Ql and Q2. 

The following table shows the affect of using various quote-functions in the 
macro-body of the declaration of X: 

If Q1(Q2) is replaced with: Then the processed expansion is: 

Ql (/UNQUOTE Q2) 10,2 

'/UNQUOTE Ql (02) 1,20 

'/.UNQUOTE Ql (/UNQUOTE 02) 1,2 

'/EXPAND 01 (02) 1,2 

'/EXPAND 01 ('/QUOTE 02 ) 1,20 

01 ('/QUOTE Q2) 10,20 

QKXQU0TE '/QUOTE '/QUOTE '/.QUOTE /QUOTE /QUOTE 02) 10, Q2 

The last two examples are especially interesting. In Ql(%QUOTE Q2), the 
%QUOTE has no effect because Q2 is at macro quote level and would not be 
bound or expanded anyhow. 

In the final example, the many occurrences of %QUOTE have the effect of 
keeping Q2 from ever being expanded. The processed macro-body for this 
example is: 

01 ('/QUOTE /QUOTE /QUOTE 02) 

This macro-body becomes the expansion of X and must be processed as such; 
the result is: 

01 ('/QUOTE Q2) 

Next, this macro-call is expanded. Before processing, the expansion is: 

10,/QUOTE 02 

Finally, this expansion is processed, giving the result shown, 10, Q2. 

The preceding example is largely concerned with macro-names. That is not 
intended to imply that quote -functions are not important for lexical-functions 
or for names other than macro-names. 
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An example of %QUOTE applied to a comma and a percent is: 

MACRO 

MACRO 

Q(A) = UPLIT(A) '/QUOTE 7, 

7 5 
X 5 
BIND 

Y = 0(4 7QU0TE, 5 7.QU0TE t G)5 

When the declaration of X is processed, the following macro-body is associ- 
ated with X: 

MACRO 

0(A) = UPLIT(A) 7,5 

The terminal percent gets into the macro-body because it was quoted in the 
declaration. The expansion of the macro-call X is exactly this same macro- 
body, and when it is processed, it establishes a declaration for Q. 

The macro-call of Q has just one actual-parameter, as follows: 

/■it 5 t G 

The commas get into the actual-parameter because they are quoted. The net 
effect of this example is to produce the declaration: 

BIND 

Y = UPLIT(4 >5 tG) 5 

An example of the use of %EXPAND is contained in the following program 
fragment: 



MACRO 

B = C 7 t 
A = B 7 t 
X = A 1 > 
XX = 7 EX 


PAND 


A 7 ; 


UNDECLARE 

'/.QUOTE A 
'/.QUOTE B 


t 

5 




OWN 
OWN 


X? 
XX 5 







The macro-call X in the first OWN declaration is expanded to the name A 
with no further expansion since the macro-name A has been undeclared. 

The macro definition of XX is B since the %EXPAND function forces expan- 
sion of the macro-call A within the macro-body for XX (prior to the 'undec- 
laration' of macro-name A). Thus the macro-call XX in the second OWN 
declaration is expanded to B, again with no further expansion since the 
macro-name B has been undeclared. 

Note that the expansion of the function 96EXPAND A within the macro-body 
for XX is not carried through to the name C. The following macro can be used 
to obtain this effect when desired: 

MACRO 

FORCE [3 = 7QU0TE 7EXPAND /.REMAINING 7,5 
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The previous example could then be extended as follows: 

MACRO 

B = C 1 > 

A = B 1 » 

X = A 1 t 

XX = '/.EXPAND A 1 , 

XXX = '/.EXPAND FORCE(A) 1 5 

UNDECLARE 

XOUOTE A t 
'/.QUOTE B5 

OWN X > 



The internally stored definition of FORCE is %EXPAND %REMAINING. 
When the macro-declaration of XXX is processed, the %EXPAND function 
causes the macro-call FORCE(A) to be expanded. Whenever a macro-call is 
expanded, all actual-parameters of the call are completely expanded. There- 
fore the actual-parameter A becomes C. That is, the body of FORCE expands 
simply to its fully expanded argument list. 

The %EXPAND function has several practical applications: 

• Compilation time can be reduced by forcing a one-time expansion of 
embedded macro-calls at macro-declaration time, rather than at every 
occurrence of the 'containing' macro-call. 

• The memory used during compilation for storing macro-bodies can be 
reduced by forcing expansion of macros involving complicated condi- 
tional-compilation syntax. 

• Further efficiencies in the use of library files can be gained by forcing as 
much expansion as possible during the library pre-compilation. 

• Macro-names declared for use within a library precompilation can be 
undeclared and thus freed for different uses in modules that refer to the 
library, if all instances of the macro-names are expanded within the li- 
brary file. 

15.5.15 Macro-Functions 

The macro-functions are especially designed for use within macro-definitions; 
they are not useful in any other context. Complete definitions of the macro- 
functions are given in this section. However, these definitions are difficult to 
understand without a discussion of macros. Examples and motivation for the 
macro-functions are given later, in Section 16.3 on macro-calls and Section 
16.4 on examples of macros. 

15.5.15.1 Definition — The macro-functions are expanded as follows: 

%REMAINING 

Expansion. Concatenate the actual-parameters not associated with for- 
mal-parameters, separating them by commas. Return the resulting se- 
quence of lexemes. 
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%LENGTH 

Expansion. Determine the number of actual-parameters for the current 
macro-call. Represent this number as a numeric-literal. Return the nu- 
meric-literal. 

%COUNT 

Expansion. Determine the recursion depth in a conditional-macro or the 
number of completed iterations in an iterative -macro. Represent this 
number as a numeric-literal. Return the numeric-literal. 

%EXITITERATION 

Expansion. Terminate the expansion of the current iteration of an itera- 
tive macro call. If a default separator or closing grouper (as specified in 
Section 16.3.3.4) is required at normal termination of an iteration, in- 
clude it. 

%EXITMACRO 

Expansion. Terminate the expansion of the smallest macro-body in 
which this lexical-function is contained, just as if the terminal % lexeme 
appeared here. 

15.5.15.2 Examples — Some examples of these functions are given as part of 
the discussion of macros in Section 16.4. 



15.5.16 Require-Function 

The require -function is the functional equivalent of the require-declaration 
(see Section 16.5); however, since it is not a declaration %REQUIRE can 
appear in any context. 

15.5.16.1 Definition — The require-function is defined as follows: 

%REQUIRE( #P ,... ) 

Restrictions. Parameters must satisfy the restrictions of the %STRING 
function (see Section 15.5.2). 

The resulting quoted-string must be a valid file-spec for the host opera- 
ting system. 

If the required file contains a %IF lexeme, it must also contain the 
matching %THEN, %ELSE (if used), and %FI of the same lexical condi- 
tion. 

During the expansion of a required file (function or declaration) a fatal 
error will occur if the end of the file is found while a macro is still being 
declared. 

A required file (function or declaration) must not appear during the 
expansion of a macro. 
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Expansion. Proceed as for the %STRING function, obtaining a single 
quoted-string for the required file. The specified file is then placed at the 
head of the input stream as the following actions are performed: 

1. The file-name default rules for the host system and the compiler are 
applied. 

2. Input from the current lexeme source is suspended. 

3. The specified file is adopted as the current lexeme source. 

4. Input from the suspended lexeme source is resumed when the speci- 
fied file is empty. 

15.5.16.2 Examples — The following depicts a required file named 
ADDMOD: 

'/.IF '/.BLISS( BLISS32 ) 
IT HEN 

,ADDRESSING_MODE( 

EXTERNAL = LONG-RELATIVE) 
'/.ELSE 

7, IF '/.BLISS* BLISS1G ) 

'/.THEN 

'» ADDRESS I NG_MODE( RELATIVE) 

7.FI 
7.FI 

And the following depicts how the file may be required: 

NODULE A( '/TITLE 'SETNODES' IDENT = '1-1' 

7,REQUIRE( 'ADDMOD' ) 

) = 
BEGIN 

t * 

END 
ELUDOM 

Note that unlike a require-declaration the require-function can appear con- 
veniently as a module-head-switch. 

The following example shows a macro-declaration that produces a fatal error 
when called: 

MACRO REQ = /REQU I RE < ' ERRMSG ' ) 1 i 

The error occurs because the %REQUIRE is encountered during the expan- 
sion of the macro. 

The following example shows a macro-declaration that is allowed: 

MACRO REQ = '/.EXPAND 

'/REQUIRE* 'ERRMSG' ) 

In the above example, the %EXPAND function expands the %REQUIRE 
function during the declaration of MACRO REQ. Notice that the percent 
lexeme, required for the termination of the macro-body, does not appear and 
is contained within the required file. 
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15.5.17 Summary of Lexical-Functions 

The following table gives one example of each lexical-function: 



Function 

7,STRING( 'ABC ' > 23 > 7,6 ' - 1 1 1 1 ' t t p h i ) 
7,EXACTSTRING(8 »7,C 'X ' , 'ABC ' ,23) 
7,CHAR(G5*GG,G7»33>97,98»33) 
7.CHARC0UNT( 'ABC ' ,23) 

'/.EXPLODE ( 'ABC ; *23) 

'/REMOVE (Q) [where is (A+l)] 

7,MAME( '+302 ' .beta) 

7.QU0TENAME ( 'F00 ' , 'BAR ' ) 

7,NULL( 'abo'.") 

'/.IDENTICAL (ABC 5 >ABC 7B'101') 

7,ISSTRING(BETA » 'BETA ' ) 
7CTCE( ALPHAC 1 ] ) 
7,LTCE( , ALPHAC 1 ] ) 

7.NBITSLK7 ,2) 
7,NBITS(7 ,2) 

'/.ALLOCATION(X) [scalar by default] 
7.S I ZE( VECTOR [ 10 , WORD 3 ) 

7FIELDEXPAND(DCB_E) 

7,ASSIGN(X »2 + 3) [X is COMPILETIME] 
7,NUMBER(Y) [ Y declared LITERAL G] 

'/.DECLARED* A) 

'/.SWITCHES (OPTIMIZE >NOCODE> 

7,BLISS(BLISS32) 

7,ERR0R('error message') 

"/., W A R N ( 'warning messase ' ) 

7. 1 N F R M ( 'information message') 

7. P R I N T ( ' t e x t in listing') 

'/.MESSAGE (' text for terminal') 

7,ERR0RMACR0( ' erro r message') 

'/.TITLE 'On Top Line of Pa3e' 

7. S B T T L 'On Second Line of P a 3 e ' 

7, U T E lexeme i comma* or percent 
'/.UNQUOTE (Binds following name) 
'/.EXPAND (Binds and e x p a n d s ) 

'/REMAINING 

'/LENGTH 

7.C0UNT 



Expansion 

'ABC23-15PHF 
'ABC23XXX' 
'ABC'abc' 
5 

'A7B7C7273' 

A+l 

+302BETA (as a name) 

FOOBAR (as a quoted 
name) 

(not a null sequence) 

1 (sequences are identical) 

(one not a string) 
(not a c-t-c-e) 

(not an 1-t-c-e) 

3 
4 

'rUPVAL 

20 (BLISS-16/32 only) 

l,0/rBPVAL,0 

empty (associates 5 with X) 
6 

1 (A is declared) 

1 (these switches are on) 

1 (under BLISS-32 compiler) 

empty (steps error count) 

empty (steps warning count) 

empty 

empty 

empty 

empty (aborts all macros) 

empty 
empty 

empty 
empty 
empty 

unmatched actual-parameters 
number of actual -parameters 
recursion or iteration count 
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Function 

XEK IT ITERATION 
ZEXITMACPn 

'/.REQUIRE ( 'ERRMSG ' ) 
7UARJAMT 



Expansion 

empty (abort iteration) 

empty (abort smallest 

macro) 

include specified file 

return decimal-literal 



April 1983 
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15.6 Lexical-Conditionals 



A lexical-conditional evaluates a compile-time-constant-expression and then, 
depending on the value of that expression, skips one or the other of two given 
lexeme sequences. In some other programming languages, this kind of facility 
is called "conditional compilation". 

Like the lexical-functions, a lexical-conditional is fully processed at compile- 
time. However, the lexical-conditional differs from a lexical-function in two 
respects. First, its syntax is different; that is just a matter of programming 
convenience. Second, and more important, it can be used to skip over a 
sequence of lexemes. 

An example of a lexical-conditional is given in Section 15.1.5. 
15.6.1 Syntax 



lexical-conditional 


%IF lexical-test 

%THEN lexical-consequence 

( %ELSE lexical-alternative ) 
\ nothing ) 

%FI 


lexical-test 


compile-time-constant-expression 


lexical-consequence ) 
lexical-alternative J 


( lexeme ... ) 
( nothing ) 



The syntactic name lexeme is defined in Section 2.2. 

15.6.2 Restrictions 

If a macro-body contains the lexeme %IF, then it must also contain the 
matching %THEN, %ELSE (if present), and %FI of the same lexical-condi- 
tional. This restriction must be satisfied by the source file before any lexical 
processing has been performed. 

The restriction just given applies not only to a macro-body, but also to an 
actual-parameter in a macro-call or lexical-function, to the file that is desig- 
nated by a require-declaration, or to the lexical-consequence or lexical-alter- 
native within another lexical-conditional. 

The keywords %IF, %THEN, %ELSE, or %FI must not be preceded by a 
quote-function. 
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15.6.3 Semantics 

The expansion of a lexical-conditional begins with the evaluation of the lexi- 
cal-test. If the low-order bit of the value of the lexical-test is 1, then the test is 
satisfied; otherwise, the test is not satisfied. 

If the test is satisfied, the lexical-consequence is subjected to lexical process- 
ing and the lexical-alternative (if present) is skipped. 

If the test is not satisfied, the lexical-consequence is skipped, and the lexical- 
alternative (if present) is subjected to lexical processing. 

When a lexical-consequence or lexical-consequence is skipped, it is not pro- 
cessed in any way; the compiler scans through, looking for the terminating 
%ELSE or %FI and ignoring everything else. 

A lexical-conditional in the macro-body of a macro-definition is not ex- 
panded; instead, it is included in the macro-body that is associated with the 
macro-name. Later, when the macro-body is used to expand a macro-call, the 
lexical-conditional is expanded. 

15.7 Compiletime Declarations 

Compile time variables provide a means to compute and assign values during 
compilation, particularly for use in combination with lexical-conditionals. 

15.7.1 Syntax 



compiletime-declaration 


COMPILETIME compiletime-item ,... ; 


compiletime-item 


compiletime-name = compiletime-value 


compiletime-name 


name 


compiletime-value 


compile-time-constant-expression 



15.7.2 Semantics 

The compiletime-declaration establishes a name wl^e value can be changed 
during compilation of the source module. In all other respects a compiletime- 
name is the same as a (non-GLOBAL) LITERAL name and can be used in all 
of the same ways that a literal name can be used. 

Observe that a compiletime-name must be given an initial value when the 
name is declared. 

The value of a compiletime-name can be changed by the %ASSIGN lexical- 
function as described in Section 15.5.9. 
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Chapter 16 
Macros 



Macros can make programs short and clear. When a certain construct is used 
often, a macro can be defined that gives the construct a name, and the name 
can then be used wherever the construct is required. By this means, a con- 
struct that is either large or unclear can be given a short, intuitive representa- 
tion. 

The idea of using the name of a construct instead of the construct itself can be 
extended in several ways, and BLISS has a variety of macro facilities. A 
programmer who wishes to use simple macros in an obvious and intuitive way 
can do so; but a programmer who wishes to use complicated macros to gen- 
erate large and intricate tables, for example, can also do that. 

This chapter is devoted to the macros and related facilities for user-defined 
expansion of source text. The first section introduces the various kinds of 
macros. The next two sections describe the declaration and call of macros. 
The final two sections describe the require- and library-declarations. 



16.1 Introduction to Macros 



The macro facilities of BLISS are important but, in some ways, difficult to 
learn. Macros are important because they can be used to add new notations to 
BLISS and thus greatly improve the organization and clarity of a program. 
The macro facilities are difficult to learn because they are innovative; most 
high level programming languages provide very limited macro facilities or 
have none at all. 

The expansion of macros is a part of lexical processing, and therefore macros 
are initially discussed at the beginning of the previous chapter. Specifically, 
the basic principles of macro expansion are presented in Section 15.1.4, and 
an example is given in Section 15.1.5. An understanding of lexical processing 
is a prerequisite for the discussion of macros in this chapter. 

This section is an informal description of a particular kind of macro, the 
simple macro. Simple macros are a good place to begin the study of macros for 
several reasons: first, they are relatively simple, as the name suggests; second, 
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they are sufficient for most programming applications; and, finally, most of 
the general techniques of macro usage can be illustrated with simple macros. 
Thus a reader who does not have a strong interest in macros can read this 
section and skip the remainder of the description of macros. 

16.1.1 Macro Declarations and Calls 

A macro has two parts: the macro-declaration and the macro-call. A macro- 
declaration contains one or more macro-definitions, and each macro-defini- 
tion associates a name, the macro-name, with a sequence of lexemes, the 
macro-body. Once a macro-name has been declared, it can be used in macro- 
calls. 

An example of a macro-declaration is: 

MACRO 

CLA = PLIK502 »-l »3> It 
ADD = PLIK402 ,0 »3> 7,5 

This declaration contains two macro-definitions. The first macro-definition 
associates the name CLA with the macro-body PLIT(502,-1,3), and the sec- 
ond associates ADD with PLIT(402,0,3). Each macro-body is terminated by a 
percent lexeme. 

Two examples of macro-calls appear in the following example: 

IF USED(REG) 

THEN CODE = CLA 
ELSE CODE = ADD? 

The macro-calls here are CLA and ADD. If this conditional-expression is 
within the scope of the macro-declaration in the preceding paragraph, then it 
is equivalent to: 

IF USED (REG) 

THEN CODE = PL I T ( 502 t - 1 »3 ) 
ELSE CODE = PLIT<402 »0 »3) 5 

Assuming that the names CLA and ADD have some mnemonic significance in 
the program from which this example is drawn, their use in the conditional- 
expression is certainly more clear than the use of the plits. 

A macro-body is processed twice. The first processing occurs when it is en- 
countered as part of a macro-definition. During that processing, no object 
code is generated by the compiler; instead, the macro-body is saved by the 
compiler as a sequence of lexemes and that sequence is associated with the 
macro-name. The second processing occurs when the macro-body is used as 
the expansion of a macro-call. During that processing, the macro-body is 
compiled in the normal way. 

16.1.2 Macros with Parameters 

A macro-definition can have a list of formal-name parameters, and these 
formal-name parameters can appear in the macro-body. When a macro-call is 
expanded, each appearance of a formal-name parameter in the macro-body is 
replaced by the corresponding actual-parameter from the macro-call. The use 
of parameters in macros can greatly increase their power and generality. 
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An example of a macro with parameters is: 

MACRO 

GETBYTE (N, I) = ( ( N ) ' s ( - ( I ) ) AND lb ' 1 1 1 1 1 1 1 1 ' ) %\ 

♦ ♦ ♦ 

X = GETBYTE( .Y+l »12)-2 5 

In this example, the list of formal-names is (N,I) and the list of actual- 
parameters is (.Y+l, 12). When the macro-call on GETBYTE is expanded, a 
copy of the macro-body associated with GETBYTE is made, and then N is 
replaced by .Y+l and I is replaced by 12. The resulting expansion is: 

<( ,Y+1 )•"(-( 12) ) AND XB'llllllU ' ) 

This expansion is placed at the head of the input stream (as described in 
Section 15.1.4) and is then compiled. Incidentally, the expansion of GET- 
BYTE(N,I) is an expression whose value is the eight-bit field (one byte) of N 
that is I bits from the right (low order) end of N. 

Just as a macro-body is processed twice, so also is an actual-parameter pro- 
cessed twice. The first processing of the actual-parameter occurs when the 
macro-body is encountered as part of a macro-call. During that processing, no 
object-code is generated, just as for a macro-body. However, macro-calls, 
lexical-functions, or lexical-conditionals encountered within the actual-pa- 
rameter are expanded during this first processing, and in this respect an 
actual-parameter differs from a macro-body. The second processing of the 
actual-parameter occurs during the expansion of a macro-call. During that 
processing, the actual-parameter is compiled like an ordinary sequence of 
lexemes. 



16.1.3 Parenthesization of Macros 

If a macro-body is an operator-expression, then it should be parenthesized; 
otherwise, a conflict of priority between the macro-body and its context may 
produce an unwanted interpretation. For similar reasons, each formal-name 
that is an operand of an operator-expression should be enclosed in 
parentheses. 

The definition of GETBYTE, given above, follows the parenthesization guide- 
lines just given. Suppose that it did not; that is, suppose the "extra" 
parentheses were not included. Then the macro-declaration would be 

MACRO 

GETBYTE(IM»I > = NM-I) AND lb ' 1 1 1 11 1 1 1 ' 7,5 

and the assignment would become: 

X = . Y+ 1- < - 1 2 ) AND lb ' 1 1 1 1 1 1 1 1 ' - 2 5 

After insertion of default parentheses in accordance with operator priorities 
given in Section 6.1.1, the assignment becomes: 

X = ( • Y ) + ( 1 " ( ~ 1 2 ) ) AND ( lb ' 1 1 1 1 1 1 1 1 ' - 2 ) 5 

This result is very different from that obtained previously, and the expression 
does not extract the desired byte value from N. 
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16.1.4 Quotation Rules and Macros 

The quotation rules, described in Section 15.2, have an important impact on 
macro usage. The following paragraphs present two examples of some of the 
less obvious effects of the quotation rules. The examples are concerned with 
the interpretation of constructs at the name-quote level. 

Because the declaration of a name is at name-quote level, and because macros 
are expanded at that level, special measures are required to redeclare a 
macro-name. An example is: 

MACRO 

ALPHA = BETA 15 
ROUTINE R = 
BEGIN 
LITERAL 

ALPHA = 1 » 
'/.QUOTE ALPHA = 2 5 

♦ ♦ ♦ 

END 

In this example, the first use of ALPHA in the LITERAL declaration is 
expanded before being declared, so that BETA is declared as a literal with 
value 1. The second use of ALPHA is quoted and therefore ALPHA is rede- 
clared as a literal with value 2. Thus, within the routine R, BETA represents 1 
and ALPHA represents 2. 

Because a name in the formal-name list of a structure, routine, or macro- 
declaration is also at name-quote level, the consideration just illustrated ap- 
plies to it. 

Because an actual-parameter is processed at name-quote level, and because 
only macro-names are bound at that level, some unexpected results can occur. 
An example is: 

MACRO 

At PI »P2) = 
BEGIN 
MACRO 

'/QUOTE '/.QUOTE M = 1 '/.QUOTE '/ 5 
LITERAL 

N = 2 5 
OUTPUTt Pi ,P2) i 
END 7, ; 
MACRO 

M = 10 '/ 5 
LITERAL 

N = 20 i 

A(M »IM) 

The macro-body for A is stored internally as: 

BEGIN 
MACRO 

'/.QUOTE M = 1 '/ 5 
LITERAL 

N = 2 ; 
OUTPUTt PI >P2) 5 
END 
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When the macro-call A(M,N) is expanded, its first actual-parameter, a 
macro-name, is bound and expanded but the second actual-parameter, a 
literal-name, is not bound (quotation rule 2). Thus the call is equivalent to: 

A ( 1 » N ) 

The expansion of this macro-call is: 

BEGIN 
MACRO 

M = 1 1 5 
LITERAL 

N = 25 
OUTPUT* 10 »N) 5 
END 

Observe that the %QUOTE before the first occurrence of M prevents the 
replacement of that occurrence of M by 10, and thus keeps the macro-declara- 
tion valid. Observe, also, that that the %QUOTE before the first % (percent) 
lexeme prevents the premature termination of the macro-body of A. The final 
result of lexical-processing is equivalent to: 

0UTPUT( 10 »2) 

Thus N is finally bound to 2, not 20. 

This discussion of the quotation rules shows that macros must be used care- 
fully. However, in the majority of cases the result will be what was expected. 
Much of the need for the quote-functions arises from the use of duplicate 
names within a given scope of your program. Such usage should be avoided 
wherever possible; the quote-functions add a level of complexity that can 
increase the chances of error. 

16.1.5 A Survey of Macros and Related Facilities 

The macros discussed in the preceding sections are simple positional macros. 
That kind of macro is of central importance in BLISS, but there are other 
kinds. Furthermore, BLISS has other facilities that are not called macros, but 
are closely related to macros. Macros and related facilities are surveyed in this 
section. 

BLISS has two main kinds of macros: positional and keyword. The difference 
between the two is in the way the actual-parameters of a macro-call are 
associated with the formal-names of the designated macro-declaration. 

In a positional macro, the order of the actual-parameters is important; that is, 
the first actual-parameter is associated with the first formal-name, the second 
actual-parameter is associated with the second formal-name, and so on. 

In a keyword macro, however, the order of the actual-parameters does not 
matter; instead, each actual-parameter is explicitly assigned to a formal- 
name. (BLISS uses the word "keyword" in two ways. In classifying macros, 
the word designates a way of handling actual-parameters; elsewhere, it desig- 
nates an identifier with a built-in meaning.) 

Positional macros are further classified as simple, conditional, and iterative. 
Simple macros are not only the simplest kind of macro but also the most 
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commonly used. Conditional- macros and iterative-macros provide two ways 
of handling macros with a variable number of parameters. 

The BLISS facilties that are related to macros are compiletime-declarations, 
require-declarations, library-declarations, and bound-declarations. 

The compiletime-declarations are described in Section 15.7. They are used to 
support macros. For example, a name that has been declared COMPILE- 
TIME can be used to designate a counter that is incremented each time a 
given macro is expanded. 

The require-declarations are described in Section 16.5. Each require-declara- 
tion designates a file of BLISS declarations. When the require-declaration is 
processed, it is replaced by the designated file. A require-declaration can be 
viewed as a specialized form of macro that, in contrast to a true macro, can go 
to another file for its body. 

The library -declarations are described in Section 16.6. A library-declaration is 
similar to a require-declaration except that it designates a file that has been 
preprocessed and thus requires minimal compilation. Library-declarations re- 
duce compilation costs. 

The bound-declarations are described in Chapter 14. They are used to associ- 
ate a value with a name. Sometimes, a programmer has a choice between a 
macro and a bound-declaration. In that situation, the bound-declaration is 
preferred. A bound-declaration not only makes the programmer's intentions 
more specific, but also is compiled more efficiently. 

The BLISS macros and related facilities can be listed in outline form as 
follows: 

Macros and Related Facilities 
Macros 

Positional Macros 
Simple Macros 
Conditional Macros 
Iterative Macros 
Keyword Macros 
Related Facilities 

Compiletime-Declarations 
Require-Declarations 
Library-Declarations 
Bound-Declarations 

All of these facilities can be used to give a name to a programming construct 
and then use that name instead of the construct. The construct may be an 
entire file of declarations as with a require-declaration or a single integer, as 
with a literal-declaration. In any case, they can greatly improve the organiza- 
tion and clarity of a program. 
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As the previous section states, every use of a macro has two parts: declaration 
and call. This section describes the macro-declarations for all kinds of BLISS 
macros. 
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A positional-macro-declaration consists of the reserved keyword MACRO, fol- 
lowed by a list of one or more macro- definitions. As with other declarations, 
the definitions are separated by commas and the declaration ends with a 
semicolon. Each macro-definition can be a simple-macro-definition, an itera- 
tive-macro-definition, or a conditional-macro-definition. 

A simple-macro-definition consists primarily of a macro-name and a macro- 
body. The name is separated from the body by an equals sign, and the body is 
terminated by a percent lexeme. The macro-name can, optionally, be followed 
by a parenthesized list of formal-names. The following macro-declaration con- 
tains a simple-macro-definition: 

MACRO 

SMI (Fl tFZ »F3> = 

( (Fl (F2)+F1 (F3) )/2) li 

In this example, the name being declared is SMI, the formal-names are Fl, 
F2, and F3, and the macro-body is: 

( (Fl (F2)+F1 (F3) ) /2) 

The percent lexeme after the macro-body is essential. Omission of the percent 
lexeme (a common programming error) causes the compiler to run wild, in- 
cluding in the macro-body everything it sees until it reaches either a subse- 
quent percent lexeme or the end of the module. 

A conditional-macro-definition is distinguished from a simple-macro-defini- 
tion by an empty pair of square brackets inserted just before the equals sign. 
An example is: 

MACRO 

CM1 (Fl »F2) [] = 

( (Fl ) -~ (F2) + CM 1 ('/.REMAINING) ) X! 

In this example, the empty brackets, [], identify the definition as a condi- 
tional-macro-definition. 

An iterative-macro-definition is distinguished from a simple-macro-definition 
by an additional list of one or more formal-names that is enclosed in square 
brackets and inserted just before the equals sign. An example is: 

MACRO 

IM1 (Fl ) CF23 = 
F1+F2 "L\ 

In this example, the bracketed list of formal-names (just one, in this exam- 
ple), [F2], identifies the definition as an iterative-macro-definition. 

A keyword-macro-declaration consists of the keyword KEYWORDMACRO 
followed by a list of one or more keyword-macro-definitions. A keyword- 
macro-definition is the same as a simple-macro-definition except that each 
formal-name can, optionally, have an explicit default-actual-parameter as- 
signed to it. The default parameter is used when a call on the macro does not 
give the corresponding actual-parameter. As example is: 

KEYWORDMACRO 

COPYUECTOR(DEST tSOURCE ,N=1 ) = 
INCR I FROM 1 TO N DO 

DESTC.I] = ♦ SOURCE C . I II 1 i 
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In this example, the default-actual-parameter 1 is associated with the formal- 
name N. Defaults are not given for the other formal-names, DEST and 
SOURCE, so the empty lexeme sequence is the implicit default-actual-pa- 
rameter for these formal-names. (For this example, the macro-call must give 
actual-parameters for DEST and SOURCE, since the use of an empty lexeme 
sequence for either of these formal-names would yield an invalid macro ex- 
pansion.) 

When a macro-definition is processed, the given macro-name is associated 
with the given macro-body. Aside from the recognition of formal-names 
within the macro-body, very little is done to the macro-body; it remains a 
lexeme sequence. No object code is generated during the processing of a 
macro-declaration. 

In fact, the processing of a macro-declaration is a relatively small part of the 
processing of a macro. Only when macro-expansion is described, in Section 
16.3, can motivation for different kinds of macro-declarations be provided. 

16.2.1 Syntax 



macro-declaration 



positional-macro-declaration ) 
keyword-macro-declaration J 



positional-macro- 
declaration 


MACRO positional-macro-definition ,... ; 


positional-macro- 
definition 


{ simple-macro-definition \ 
I conditional-macro-definition > 
V iterative-macro-definition / 


simple-macro- 
definition 


macro-name i < macro-formal-name ,...)) 
( nothing J 

= macro-body % 


conditional-macro- 
definition 


macro-name [ < macro-formal-name ,... ) J 
( nothing ) 

[ ] 

= macro-body % 
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iterative-macro- 
definition 


macro-name [ < fixed-formal-name ,...)) 
( nothing J 

[iterative-formal-name ,...] 

= macro-body % 


macro-name \ 
macro-formal-name 1 
fixed-formal-name | 
iterative-formal-name J 


name 


macro-body 


( lexeme ... ) 
( nothing J 



keyword-macro- 
declaration 


KEYWORDMACRO 
keyword-macro-definition ,... ; 


keyword-macro- 
definition 


macro-name 
( keyword-pair ,... ) 
= macro-body % 


keyword-pair 


keyword-formal-name ( = default-actual ) 

{ nothing J 


macro-name ) 
keyword-formal-name J 


name 


macro-body ) 
default-actual J 


( lexeme ... ) 
( nothing J 



The syntactic name lexeme is defined in Section 2.2. 
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16.2.2 Restrictions 

Only a conditional-macro with one or more macro-formal-names can be used 
recursively. That is, the macro-body of any other macro must not contain a 
call on itself or a call on another macro that ultimately results in a call on the 
macro being defined. 

A % (percent) in a macro-body must be quoted. It is quoted if it immediately 
follows an odd number of %QUOTE functions; that is, 

%QUOTE, or 

%QUOTE %QUOTE %QUOTE, or so on. 

(Otherwise, the % would terminate the macro-body.) 

A macro-body must not end with an odd number of %QUOTE functions. 
(Otherwise, the % (percent) that terminates a macro-body would become part 
of the macro-body.) 

A default-actual in a keyword-macro-declaration must satisfy the restrictions 
on an actual-parameter in a macro-call. (Literal commas must be quoted, 
parentheses must be balanced, and an odd number of quotes must not occur 
at the end; see Section 16.3.2.) 

16.2.3 Semantics 

When the compiler encounters a macro-declaration, it processes the macro- 
definitions in the declaration one by one in the order in which they appear. 

This section describes both the lexical processing and final interpretation of a 
macro-definition. 

16.2.3.1 Lexical Processing of Macro-Definitions — Lexical processing of a 
macro-definition is performed at two quote levels, neither of which is the so- 
called "normal" quote level. Indeed, the main reason BLISS has special quote 
levels is to properly support macro-definitions. 

The following paragraphs specify the quote level for each part of a macro- 
definition. The definitions of the quote levels, given in Section 15.2.1, are 
reviewed here. 

The macro-body of a macro-definition is processed at macro-quote level. At 
this level, the compiler 

• Binds any occurrence of a name that is a formal-name in the macro- 
definition. 

• Expands any quote-function, namely: %QUOTE, %UNQUOTE, or 
%EXPAND. 
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These actions are the minimum lexical processing. They leave most of the 
processing of a macro-body to later, when the macro is expanded at the point 
of call. 

Each default-actual-parameter in a keyword-macro-definition is also pro- 
cessed at macro-quote level. 

The macro-name and the formal-names (if any) are processed at name-quote 
level. At this level, the compiler 

• Binds macro-names only. 

• Expands lexical-functions and macro-calls. 

These actions can produce unexpected results, as illustrated in Section 15.6.4. 

16.2.3.2 Interpretation of Macro-Definitions — As lexical-processing of a 
macro-definition is performed, the compiler forms the definition of a macro, 
which it retains for use when a call on the macro is encountered. The defini- 
tion contains the following information: 

• The kind of macro; that is, simple, iterative, conditional, or keyword. 

• The number of formal-names. For iterative macros, the distinction be- 
tween fixed- and iterative-formal-names. For a keyword-macro, a list of 
the formal-names and the default-actual-parameters (if any) for each. 

• A copy of the macro-body, with each formal-name properly identified as 
such. 

16.2.4 Predeclared Macros 

Three macro-names are predeclared in each BLISS dialect, %BLISS16, 
%BLISS32, and %BLISS36. The definition of these macro-names in 
BLISS-32, for example is as follows: 

MACRO 

XBLISSIGU = 1 t 

7.BLISS3BC3 = 7,. » 

2.BLISS32C] = '/.REMAINING '/, i 

(In each of the other dialects the %REMAINING lexical function occurs in 
the definition of the appropriate name). This is not a valid declaration to give 
in a program because the "names" in the declaration begin with "%" and are, 
in fact, reserved keywords rather than names (see Appendix A) . However, the 
declaration does convey the interpretation given these identifiers. 

The example declaration causes the BLISS-32 compiler to replace each call 
on 96BLISS16 and %BLISS36 by the null lexeme and to replace each call on 
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%BLISS32 by the actual-parameter sequence in the call. Each BLISS com- 
piler predeclares these macro-names so that only the macro-name associated 
with the applicable language (BLISS-16, BLISS-32, or BLISS-36) expands to 
a non-null sequence. 

By means of calls on these predeclared macros, a programmer can specify 
processor dependencies. Then, when the program is compiled, only the actions 
relevant to the given processor are retained. 



16.3 Macro-Calls 



Once a macro has been defined, it can be invoked by a macro-call. BLISS has 
two kinds of macro-call, corresponding to the two main kinds of macro-decla- 
ration, positional and keyword. This section describes both kinds of macro- 
call. 

A positional-macro-call consists of a macro-name followed by an optional list 
of actual-parameters. The list of parameters is normally enclosed in 
parentheses; however, square brackets or angle brackets can be used instead, 
without changing the interpretation of the call. An actual-parameter can be 
nearly any sequence of lexemes. 

An example of a positional-macro-call is: 

ALPHA(A ».B + 3 » 'qrs ' IB MODULE) 

In this example, the macro-name is ALPHA. The first and second actual- 
parameters are A and .B+3, which happen to be valid BLISS expressions; 
however, they are not compiled as such until after the call has been expanded. 
The third actual-parameter is a sequence of three lexemes that does not 
appear to make sense in BLISS; however, there is nothing inherently wrong 
with the use of this sequence as a macro actual-parameter. In order for this 
example to be a valid macro-call, it must lie within the scope of a declaration 
of ALPHA as a positional macro; and that declaration must make some valid 
use of the given actual-parameters. 

A keyword-macro-call is similar to a positional-macro-call except that a name 
must be associated with each actual-parameter. The name and actual-param- 
eter are separated by an equals sign. The name must be one of the keyword- 
formal-names in the definition of the given macro. 

An example of a keyword-macro-call is: 

GAMMA (X=Q(R »1 ) »Y=3) 

It is assumed that this call occurs in the scope of a declaration of GAMMA as 
a keyword-macro name. That declaration must have X and Y as formal- 
names. 
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16.3.1 Syntax 



macro-call 


( positional-macro-call ) 
\ keyword-macro-call J 


positional- 
macro-call 


/ ( macro-actuals ) \ 

macro-name ) [ macro-actuals ] I 
1 < macro-actuals > f 
v nothing / 


macro-actuals 


( macro-actual-parameter ,... ) 
\ nothing J 


keyword - 
macro-call 


t ( keyword-assignments ) J 

macro-name / [ keyword-assignments ] > 

(, < keyword-assignments > / 


keyword - 
assignments 


( keyword-assignment ,... ) 
\ nothing ) 


keyword- 
assignment 


keyword-formal-name = macro-actual-parameter 


macro-actual- 
parameter 


( lexeme ... ) 
X nothing ) 


macro-name \ 

keyword- / 

formal-name ) 


name 



The syntactic name lexeme is defined in Section 2.2. 

The characters < and > are usually called less than and greater than. In this 
section, they are called left angle bracket and right angle bracket. 

16.3.2 Restrictions 

The macro-name in a positional-macro-call must be declared in a positional- 
macro-declaration. Similarly, the macro-name in a keyword-macro-call must 
be declared in a keyword-macro-declaration. 
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Each keyword-assignment in a keyword-macro-call must begin with a formal- 
name from the declaration of the designated keyword-macro. No formal-name 
can be used more than once in a keyword-macro-call. 

A macro-actual-parameter must not contain unbalanced parentheses or 
brackets. That is, every left parenthesis must be followed (somewhere in the 
same macro-actual-parameter) by a matching right parenthesis; every left 
square bracket, by a matching right square bracket; and every left angle 
bracket by a matching right angle bracket. 

A , (comma) in a macro-actual-parameter must be quoted or parenthesized. It 
is quoted if it immediately follows an odd number of %QUOTE functions. It is 
parenthesized if it is enclosed in a balanced pair of parentheses or brackets 
that is, itself, contained in the macro-actual-parameter. 

A macro-actual-parameter must not end with an odd number of %QUOTE 
functions. (Otherwise, the following comma would be quoted). 

If the macro-name of a macro-call is declared as a simple macro with no 
formal-names, then the macro-call must consist of just the macro-name. (This 
does not say that the macro-name cannot be followed by something that looks 
like a parenthesized list of actuals; it only says that the compiler will not 
process that construct as part of the macro-call.) 

If the macro-name of a macro-call is declared other than as a simple macro- 
call with no formal-names, then the macro-call must have a parenthesized (or 
bracketed) list of actual-parameters. (The list can be empty, but the pair of 
parentheses or brackets must be there.) 

16.3.3 Semantics 

A macro-call is first subjected to lexical-processing and then expanded. Lexi- 
cal-processing is the same for all macro-calls, and is described in the next 
section. Expansion is different for the different kinds of macros, and is de- 
scribed in four separate sections. 

The expansion of a macro-call can be cut short by a %EXITITERATION or 
%EXITMACRO lexical -function; these functions are described in Section 
15.5.14. 

16.3.3.1 Lexical Processing of Macro-Calls — The processing of a macro-call 
begins when a macro-name is bound to a macro-declaration. 

Once a macro-name has been bound, the actual-parameters (if any) are pro- 
cessed at name-quote level. At this level, the compiler: 

• Binds macro-names only. 

• Expands lexical-functions and macro-calls. 

Because the compiler expands lexical-functions and macro-calls at this level, 
an expansion can occur within another expansion. The actual-parameters of a 
macro-call are separated by commas. However, a comma that is quoted or 
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parenthesized is treated literally. (See "Restrictions", Section 16.3.2, for the 
definition of a quoted or parenthesized comma.) 

The list of actual-parameters is terminated by the right parenthesis or bracket 
that matches the left parenthesis or bracket that begins the list. 

The following list gives some macro-calls and identifies the actual-parameters 
in these calls. Because some macro-calls are included in the actual-parame- 
ters, the following macro-definitions are given first: 

MACRO 

M1(F1,F2) = Fl » F1/F2 » .F1*F2 It 



M2 



= A > Bt C t D li 



The identification of the actual-parameters al, a2, ... is given in the following 
list: 



Macro-Call 

M3(X »Y »Z) 

M3(XtY K.QUOTE » Z»W) 

M3(M1 (X tY) ) 

M3(M2) 

M3(X f'XOUOTE Ml <X fY> »Z) 

M3(X » (Y »Z) »N) 

M3(X »FEM2] fY) 



al a2 



a3 a4 



X 


Y 








•y 


X 


Y t Z 








w 


X 


X / Y 








X*Y 


A 


B 








C 




MUX 


t x 


') 






A 


( Y » Z 


) 






W 


V 


FCA , 


B 


> C 


>D3 


Y 



16.3.3.2 Expansion of Simple Macros — The compiler uses the following 
algorithm for expanding a simple macro-call: 

1. Associate Actuals with Formats. Associate the first actual-parameter 
with the first formal-name of the corresponding definition, the second 
actual-parameter with the second formal-name, and so on. 

a. If there are too many t actual-parameters, save the extra actual- 
parameters for use in the value of %REMAINING. 

b. If there are too few actual-parameters, associate the empty lexeme 
sequence with each formal-name that does not have an actual-pa- 
rameter. 

2. Prepare Macro-Body. Make a copy of the macro-body of the corre- 
sponding definition. In the copy, replace each unquoted occurrence of a 
formal-name with the corresponding actual-parameter. 

3. Expand Macro-Functions. Replace certain lexical-functions in the copy 
of the macro-body as follows: 



a. %LENGTH 



becomes an unsigned integer-literal that repre- 
sents the number of parameters in the list of ac- 
tual-parameters. 
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b. %REMAINING becomes a list of the extra actual-parameters. 

If the macro-definition has n formal-names, then 
%REMAINING is replaced by the following lex- 
eme sequence: the (n+l)'th actual-parameter, a 
comma, the (n+2)'th actual-parameter, a comma, 
and so on, ending with the last actual-parameter. 

If there are no extra actual-parameters, %RE- 
MAINING is replaced by the empty lexeme se- 
quence. 

c. %COUNT becomes 0. 

4. Place Expansion in Stream. Place the modified copy of the macro- 
body at the head of the input stream. 

16.3.3.3 Expansion of ConditionaTMacros — The compiler uses the following 
algorithm for expanding a conditional macro-call: 

(The semantics of conditional-macros is quite similar to those of simple- 
macros. In the following, each item that differs from simple-macros is marked 
with a star (*).) 

1. Associate Actuals with Formals. Associate the first actual-parameter 
with the first formal-name of the corresponding definition, the second 
actual-parameter with the second formal-name, and so on. 

a. If there are too many actual-parameters, save the extra actual- 
parameters for use in the value of %REMAINING. 

*b. If there are too few actual-parameters, use the empty lexeme se- 
quence as the expansion of the macro-call and exit from this algo- 
rithm. 

*c. If there are no actual-parameters in the call and no formal-names in 
the macro-definition, use the empty lexeme sequence as the expan- 
sion of the macro-call and exit from this algorithm. 

2. Prepare Macro-Body. Make a copy of the macro-body of the corre- 
sponding definition. In the copy, replace each unquoted occurrence of a 
formal-name with the corresponding actual-parameter. 

3. Expand Macro-Functions. Replace certain lexical-functions in the copy 
as follows: 

a. %LENGTH becomes an unsigned integer-literal that repre- 

sents the number of parameters in the list of 
actual-parameters. 
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b. %REMAINING becomes a list of the extra actual-parameters. 

If the macro-definition has n formal-names, then 
%REMAINING is replaced by the following lex- 
eme sequence: the (n+l)'th actual-parameter, a 
comma, the (n+2)'th actual-parameter, a comma, 
and so on, ending with the last actual-parameter. 

If there are no extra actual-parameters, %RE- 
MAINING becomes the empty lexeme sequence. 

*c. %COUNT becomes an unsigned integer-literal that repre- 

sents the depth of recursion for this macro. 

If the macro-definition has no formal-names, then 
recursion is not permitted, and %COUNT always 
becomes 0. 

The depth of recursion is the number of calls on the same macro that 
occurred prior to the current call and are still in the process of being 
expanded. 

4. Place Expansion in Stream. Place the modified copy of the macro- 
body at the head of the input stream. 

16.3.3.4 Expansion of Iterative-Macros — The compiler uses the following 
algorithm for expanding an iterative macro-call: 

1. Associate Actuals with Fixed-Formals. Associate the first actual-pa- 
rameter with the first fixed-formal-name of the macro-definition, asso- 
ciate the second actual-parameter with the second fixed-formal-name, 
and so on. 

a. If there are one or more extra actual-parameters, call them the 
remaining-actuals-list, and go to Step 2. 

b. Otherwise, use the empty lexeme sequence as the expansion of the 
macro-call and exit from this algorithm. 

2. Prepare Fixed-Macro-Body. Make a copy of the macro-body of the des- 
ignated macro-definition. In that copy, replace each unquoted occur- 
rence of a fixed-formal-name by the corresponding actual-parameter. 
Call the result the fixed-macro-body. 

3. Expand %LENGTH Macro-Function. Replace any %LENGTH lexi- 
cal-function in the macro-body with its expansion, as follows: 

%LENGTH becomes an unsigned integer-literal that repre- 

sents the number of parameters in the list of ac- 
tual-parameters. 

(The next four steps, Step 4 through Step 7, are a loop. Each pass through 
the loop generates a new copy of the macro-body. These copies are placed 
on the input stream in Step 8.) 
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4. Associate Actuals with Iterative-Formals. Associate the first actual- 
parameter of the remaining-actuals-list with the first iterative-formal- 
name of the macro-definition, associate the second actual-parameter 
with the second iterative-formal-name, and so on. 

As each actual-parameter is associated with an iterative-formal-name, 
remove it from the remaining-actuals-list. If there are too few actual- 
parameters, associate the empty lexeme sequence with each iterative- 
formal-name that does not have an actual-parameter. 

Steps la and 7 of this algorithm guarantee that there will always be at 
least one remaining actual-parameter at the beginning of this step. 

5. Prepare Iterative-Macro-Bodies. Make a copy of the fixed-macro-body 
(obtained in Steps 2 and 3). In that copy, replace each unquoted occur- 
rence of an iterative-formal-name by its associated actual-parameter 
(obtained in Step 4). 

6. Expand Other Functions. Replace any occurrences of the %COUNT or 
%REMAINING function in the iterative-macro-body as follows: 

a. 96COUNT becomes an unsigned numeric-integer that repre- 

sents the iteration count for this iteration. 

The iteration count is the number of completed 
iterations; thus the count is the first time this 
step is executed, 1 the second time, and so on. 

b. %REMAINING becomes the remaining-actuals-list. 

7. End Test. If the remaining-actuals-list is not empty, go back to Step 4. 

8. Place Expansion in Stream. Place the following sequence of lexemes at 
the head of the input stream: 

a. The default left grouper, if any. 

b. The copies of the macro-body prepared in Step 4 through Step 6. 
Place a default separator between each pair of copies. 

c. The default right grouper, if any. 

The final step of the algorithm just given requires default punctuation. 
Specifically, Step 8b requires a default separator, and Step 8a and Step 8c 
require default groupers. 

The selection of default punctuation for a given macro-call depends on the one 
or two lexemes that immediately precede the macro-call. Those lexemes are 
called the left context, and they are examined only after their lexical process- 
ing is complete. 

BLISS has five combinations of default separator and default groupers. The 
first three use a comma, a semicolon, or an operator as the separator and do 
not use groupers. The fourth uses a semicolon as a separator and parentheses 
as groupers. The fifth uses a semicolon as a separator and SET and TES as 
groupers. 
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The left context for each of the five combinations is given in the following list, 
together with remarks that show why those defaults are appropriate. 

1. Comma Separators, No Groupers. In the following cases, the default 
separator is a comma and default groupers are not used: 



Left Context 

( 



Remarks 

The expansion serves as a list of actual- 
parameters, formal-names, or plit-items. 



The keyword phrase 
at the beginning 
of a declaration 

, (comma) 



The expansion serves as a list of declaration- 
items. 

The expansion serves as the continuation of a 
list of actual-parameters, formal-names, plit- 
items, or declaration-items. 

This case does not apply to a "(" that is first lexeme of a block or an 
expression. 

Semicolon Separators, No Groupers. In the following cases, the default 
separator is a semicolon and default groupers are not used: 



Left Context 

BEGIN 

( 

SET 



Leading keyword of 
control-expression 



Remarks 

The expansion serves as the contents of a 
block as defined in Section 8.1.1. 

The expansion serves as a sequence of case- 
lines in a case-expression or select-lines in a 
select-expression. 

(not a useful default) 



CODECOMMENT (not a useful default) 

; The expansion serves as the continuation of a 

sequence of declarations, block-actions, case- 
lines, select-lines. 

This case applies to a "(" only if it is the first lexeme of a block or an 
expression. 

Operator Separator, No Groupers. In the following cases, the default 
separator is a copy of the specific operator that precedes the macro-call 
and default groupers are not used. 



Left Context 

operator 



Remarks 

The expansion serves as the continuation of 
the operator- expression that begins in the 
left context. 



This case applies to all operators (both delimiters and keywords) in the 
table in Section 5.1.1. 
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4. Semicolon Separator, SET ... TES Groupers. In the following cases, 
the default separator is a semicolon and default groupers are "SET" 
and "TES". 

Left Context Remarks 

OF The expansion serves as the body of a case- 

expression or a select-expression. 

This case applies to the keyword "OF" when it appears in a case- 
expression or a select-expression. 

5. Comma Separator, Parenthesis Groupers. In the following cases, the 
default separator is a comma and the default groupers are parentheses. 

Left Context Remarks 

name The expansion serves as a parenthesized list 

literal of actual-parameters or formal-names. (This 

attribute default is based on the assumption that the 

psect-attribute left context gives the address of a routine or a 

switch data segment; the usefulness of that assump- 

list-option tion varies from one situation to another.) 

linkage -type 

linkage- modifier 

) 

] 

> 

END 

TES 

(not a useful default) 

OF The expansion serves as a repeated group of 

plit-items. 

This case applies to the keyword "OF" when it appears in a plit-group. 

16.3.3.5 Expansion of Keyword-Macros — The compiler uses the following 
algorithm for expanding a keyword macro-call: 

1. Associate Actuals with Formals. Associate actual-parameters with for- 
mal-names as indicated by the keyword-assignments in the macro-call. 

If the macro-call does not include a keyword-assignment for a particular 
formal-name, then use the corresponding default-actual from the decla- 
ration of the macro. If the declaration does not have such a default- 
actual, then use the empty lexeme sequence. 

2. Complete Expansion. Complete the expansion of the macro-call as if it 
were a simple-macro-call (starting with Step 2 of Section 16.3.3.2). 

16.3.4 Discussion 

The following discussion of macros begins with easy examples and continues 
with a section on the default punctuation of iterative macros. 
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16.3.4.1 Introductory Examples — Four examples of macro-declarations were 
given in the preceding section on macro-declarations. In the following para- 
graphs, each of those declarations is given again with an accompanying call 
and the expansion of the call. 

The example of a simple-macro is: 

MACRO 

SMI (Fl »F2 »F3) = 

( (Fi (F2)+F1 (F3) > /2) % 5 
♦ « ♦ 
SMI (ROUT ,0 f .A+.B) 

The expansion of the call on SMI is: 

< (R0UT(0)+R0UT( . A+.B) ) /2> 

In this and subsequent examples, it is assumed that the macro-call appears in 
a context in which it plays a valid and useful role; space does not permit the 
presentation of such a context here. 

The example of a conditional-macro is: 

MACRO 

CM1 (Fl »F2) E3 = 

Fl = ,F1 - -F2 i 

CM! ('^REMAINING) % 5 
CM1(A»0»B»G»C»2) 

The expansion of the call on CM1 proceeds recursively, as follows. The origi- 
nal call yields: 

a = . a - - o ; 

CMl (B »B tC »2) 

Next, the new call is expanded, and the accumulated result is: 

A = .A "' -05 
B - . B ''' - B 5 
CMi (C »2) 

Once more the new call is expanded, giving: 

A = .A - - 5 

B = ♦ B ''' - B 5 

C = ♦ C - - 2 5 
CM( ) 

This time, the new call has insufficient parameters, and its expansion is the 
null lexeme sequence, so the final result is: 



A = 


.A '• 


- 5 


B = 


.B - 


-s; 


C = 


.c - 


-2 5 



The significant feature of this macro is that it can accept any number of pairs 
of actual-parameters, and produces an assignment for each. 

An example of an iterative- macro is: 

MACRO 

IMi(Fl)CF23 = 
F1+F2 15 
... 
PLITt IM1 (Z »A »B »C fD ♦ ) ) 
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The expansion of the call on IM1 is: 

2 + A >2 + B t2 + C >2 + D 

Thus the macro-call provides (in this example) four plit-items for the plit. 

The example just given illustrates two of the special features of iterative- 
macros. First, it shows how some parameters (just the first one in this exam- 
ple) can be used in each iteration of the expansion while the remaining 
parameters are used up (one at at time in this example) by the individual 
iterations. Second, the example shows that the iterations are separated by a 
lexeme (comma in this example) that depends on the context (a plit in this 
example). 

An example of a keyword macro is: 

KEYWORDMACRO 

CQPYOECTOR(DEST f SOURCE »N=1 ) = 
INCR I FROM 1 TO N DO 

DESTC.I] = ♦S0URCEC.I3 X5 

♦ ♦ ♦ 

C0PY0ECT0R(N=10 »DEST=V2 »S0URCE=V1 ) 5 

The expansion of the call on COPYVECTOR is: 

INCR I FROM 1 TO 10 DO 
02 CI 3 = .Vic, I] 5 

The main advantage of keyword macros over simple macros is that the actual- 
parameters need not be given in the same order as the formal-names. That is 
useful when the order of the formal names is hard to remember; that is, when 
there are many parameters or when there is no natural order. This example 
illustrates such a situation. 

16.3.4.2 Default Punctuation — Section 16.3.3.4 defines the default punctua- 
tion for iterative-macros. This section further discusses that aspect of BLISS 
and gives some examples. 

The default punctuation of an iterative macro-call is based on an examination 
of the context in which the macro-call appears. The context used by the 
compiler is minimal (the one or two lexemes that precede the call), but it 
usually provides the result the programmer wants. 

Some examples of default punctuation arise in the processing of the following 
program fragment: 

MACRO 

SHIFTCA>B] = A'B X i 
BIND 

PTR = PLIT( 

SHIFT( 1 ,2 ,3 ,4 >5 ,G) t 

+ SHIFK 1 >Z »3 .4) ) 5 

In this example, the macro SHIFT is called twice. After expansion of these 
macro-calls, the BIND expression is: 

BIND 

PTR = PLIT( 

1 - 2 1 3 - a 1 5 - G f 
0+1 "2 + 3 "4> ; 
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The first macro-call appears after the lexemes "PLIT(", and quite obviously 
should supply one or more plit-items; therefore, commas, which are the 
separators in a list of plit-items, are supplied as default punctuation. The 
second macro-call appears after the lexeme "+", and (perhaps not so obvi- 
ously) should supply a sequence of operands; therefore, the operator, "+" in 
this case, is supplied as the default punctuation. 

The default punctuation is not always the punctuation that the programmer 
wants. A programmer who wants something else can either avoid the use of an 
iterative macro or else change the context. The second macro-call in the 
preceding example is an example of a change of context: the "0+" before the 
call changes its context without changing the value of the plit-item provided 
by the call. 

Consider an iterative-macro-call that occurs at the beginning of a macro- 
actual-parameter in a larger macro-call. The iterative-macro-call is expanded 
prior to the containing macro-call; therefore, its context is just the left paren- 
thesis, left bracket, or comma that precedes it in the actual-parameter list. 
Later, the actual-parameter replaces a formal-name in a macro-body, but 
that is too late to affect the expansion of the embedded iterative -macro. This 
aspect of macro-expansion limits the usefulness of iterative-macro-calls. 

An example of default punctuation that uses default brackets arises in the 
processing of the following block. 

BEGIN 
MACRO 

CASEGEN( INDEX) C ] = 
BEGIN 
MACRO 

CASELINECACTION] = 

CXCOUNT]; ACTION XOUOTE %\ 
CASE INDEX FROM TO XLENGTH-2 OF 

CASELINE(XREMAINING) 
END'/, 5 

* * + 

CASEGEN( ♦ I t 01 » 02. 03 > S 

end; 
After macro expansion, this block is: 



BEGIN 



BEGIN 

CASE . I FROM TO 4-2 OF 

SET 

C03: 1 i 

[Us 02 5 

C2]s 03 

TES 
END 



END 



The default brackets, SET and TES, were supplied by the compiler because 
the macro-call on CASELINE was expanded in the left context of "OF" in a 
case-expression. 
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Observe that a containing block is generated by the macro CASEGEN be- 
cause it contains a nested macro-definition. The generation of a containing 
block is advisable for two reasons. First, the macro CASEGEN can then be 
called in any context, not just at the end of the declarations in a block. 
Second, the name of the nested macro is then confined to the scope of the 
generated block and is, therefore, not known at the same block level as the 
name CASEGEN. 



16.4 Examples of Macros 



This section provides some relatively advanced examples of the use of macros. 
It gives some idea of the variety of tasks that macros can handle. However, 
space does not permit a complete or detailed exploration of macros. 

16.4.1 Macros for Initializing a BLOCK Structure 

When a BLOCK structure is used in a program, its fields can be initialized 
conveniently by means of a macro. An example of this application of macros 
follows. 

Suppose a BLISS-32 block structure that has the following layout is required: 



CNT 



OFFSET 



VAL 



Let this structure be called a QVAL block, and suppose that its fields have the 
following properties: 

Field Size (in bits) and Extension 



OFFSET 


16 


UNSIGNED 


F 


3 


UNSIGNED 


CNT 


13 


SIGNED 


VAL 


32 


SIGNED 



The fields are laid out in the order of increasing byte addresses, with OFFSET 
first, then F, and so on. Thus OFFSET occupies the first word, F occupies the 
low-order 3 bits of the second word, CNT occupies the remaining bits of that 
word, and VAL occupies the third and fourth 16-bit words (that is, the entire 
second fullword). 

The following simple-macro provides for initialization of a QVAL block: 

MACRO 

INIT_QVAL(OFFSET >F »CNT »UAL) = 
INITIAL* W0RD(0FFSETf 

((F) AND 7,0 '7') OR ((CNT) "3 AND 7,0 ' 1 77770 ')) » 
LONG (MAD) 7,5 
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This macro "packs" four values, one for each field, into the correct layout for 
a QVAL block. Consider the following use of the macro: 

OWN 

X: BL0CKC0VAL-SIZE3 I N I T_QVAL ( » 3 , - 1 »2 ) 5 

When the macro is expanded, the declaration becomes: 

OWN 

X: BLOCKCQVAL-SIZE] INITIAL* WORD ( >10 ' 1 77773 ') , L0NG(2)); 

Observe that the values for F and CNT are packed into the second word by 
masking their values, shifting the CNT value three bits left, and then combin- 
ing the values with an OR operator. 

The use of macros described here supports the declaration and referencing of 
the BLOCK structures described in Chapter 11. 

16.4.2 A Complicated Macro 

Sometimes it is appropriate to use a macro for a relatively specialized and 
complicated purpose. An example of such an application is: 

MACRO 

BLOCKSETUP (A) C3 = 

OWN As BLOCK ClOl 5 

ROUTINE XNAME <A»'_INIT'): NOUALUE = 
BEGIN 

incr I from o to a do ! Zero the block 

'/.NAME (A) C ♦ I »0 »32 »0] = 5 

fill (A* '/.REMAINING) ! Set fields 

end; 

X t 
FILL (A)CB] = A B li 

These macros declare a given name (represented by the formal-parameter A) 
as an OWN BLOCK composed of ten longwords. In addition, they declare a 
routine that, when called, initializes the block. The routine begins by setting 
all ten longwords to zero and then initializing any number of specified fields 
within the block. 

Suppose that two of the fields within the block are given names as follows: 

MACRO 

ALPHA = OtBtBtOlt 
BETA = 5»0»lBtl5f. J 

It is assumed that ALPHA and BETA are the only fields that require initiali- 
zation. Then an example of a call on the macro BLOCKSETUP is: 

BLOCKSETUP(QQ » [ALPHA] = 25. [BETA] = 32)? 
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The expansion is: 

OWN 

QQ; BLOCK [10] 5 
ROUTINE 

QQ„INITs NOVALUE = 
BEGIN 
I NCR I FROM TO 9 DO 

QQ[ . I .0 »32 »01 = Oi 
OOCO»8i8»03 = 255 
00C5»0»1B»1] = 32 5 
END i 

Given these declarations, a call on QQ INIT (without any actual-parame- 
ters) will zero QQ and set two of its fields. 

16.4.3 Nested Macro Definition 

A macro definition can be given within a macro definition, as follows: 

MACRO 

Mi (Fl »F2) C3 = 

OWN Fl f F25 

MACRO NM1 CF3 >F43 = 

LOCAL XNAME(F3 » ' .... 1 ' ) » 7.NAME ( FA » ' _.. 1 ' ) 5 '/.QUOTE li 
NM1 (Fl »F2 ^REMAINING) 
"L \ 

The %QUOTE lexical-function prevents the % lexeme from being lexically 
bound and thus from being interpreted as the termination lexeme for the 
macro body of Ml. An example of a call on the macro Ml is: 

Ml ( A * B , C » D t E , F) 

The result of this call is the following expansion: 

OWN A »Bi 
LOCAL A_l iB_l 5 
LOCAL C_l >D_1 ; 
LOCAL E_l »F_1 5 

16.4.4 Declarations within Macros 

Declarations within macros can lead to problems. For example: 

BEGIN 
MACRO 

S ( A , B ) = 
BEGIN 

local c; 

C = .A + , B ", 
.C 

END 1 ? 
OWN C »Xi 

s ( c # x ) ; 

S('£UNQU0TE C »>•(> ; 
END 
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In the first call on S, the substitution of the actual-parameter C in the macro 
body causes it to be interpreted as the local variable declared in the macro 
body. The second call on S avoids this problem by the use of the %UN- 
QUOTE lexical-function. 



16.5 Require-Declarations 



A require-declaration specifies the name of a file. When the module is com- 
piled, the require-declaration is replaced by the contents of the file. Text that 
is common to a number of separate modules can be made into a single file 
and, in this way, included in each module (also see Section 15.5.16). 

The most common use of a require-declaration is in connection with a file that 
contains structure-declarations, field-declarations, macro-declarations, and 
literal-declarations common to several related modules of a program. 

16.5.1 Syntax 



require-declaration 


REQUIRE file-designator ; 


file-designator 


quoted-string 



The syntactic name quoted-string is defined in Section 4.3. 

16.5.2 Restrictions 

The file-designator given in a require-declaration must be a valid file name on 
the system on which the compiler is running. 

The result of replacing the require-declaration with the specified file must be 
a valid module. 

If the required file contains a %IF lexeme, it must also contain the matching 
%THEN, %ELSE (if used), and %FI of the same lexical condition. 

During the expansion of a required file (declaration or function) a fatal error 
will occur if the end of the file is found while a macro is still being declared. 

A required file (declaration or function) must not appear during the expansion 
of a macro. 



16.5.3 Semantics 

The specified file is placed at the head of the input stream. More precisely, 
the following actions are performed: 

1. Locate the file specified by the file-designator. File name default rules 
are given in the appropriate BLISS user's guide. 
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2. Suspend input from the current lexeme source. 

3. Adopt the specified file as the current lexeme source. 

4. When the specified file is empty, resume input from the lexeme source 
that was suspended in Step 2. 



16.6 Library-Declarations 



A library-declaration calls upon a file that has been precompiled. The effect is 
to introduce a set of declarations into a module without compiling them. 

Before a library declaration can be compiled, a separate compilation activity 
must be performed. That is, a library source file must be created by the 
programmer, compiled as described in the appropriate BLISS user's guide, 
and saved as a library binary file. It is the latter file that is used when the 
library-declaration is compiled as part of a module. 

A library-declaration (and the associated precompilation) is chosen over a 
require-declaration entirely for reasons of efficiency: it can reduce compilation 
costs. Most of the cost associated with compiling a library file is done during 
precompilation. Therefore a saving results if the library file is used in several 
modules or if it is revised less often than the modules in which it is used. 

Aside from efficiency, a given library-declaration has the same effect as an 
analogous require-declaration. 

16.6.1 Syntax 



library-declaration 


LIBRARY file-designator ; 


file-designator 


quoted-string 



The syntactic name quoted-string is defined in Section 4.3. 

16.6.2 Restrictions 

The file specified by the library-declaration must be a library binary file 
produced by the same compiler that is compiling the library-declaration. 

The result of replacing the library-declaration with the associated library 
binary file must be a valid module. (The compiler does x not actually perform 
this replacement, but such a replacement is easy to imagine). 

The associated library source file must not contain any use of a name that is 
not declared in that file. 
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The associated library source file must consist of a sequence of declarations. 
Only certain kinds of declarations can be used. These declarations, listed 
according to the chapters in which they are described, are: 



external-declarations 

structure-declarations 
field-declarations 

external-routine-declarations 

linkage-declarations 

external-literal-declarations 
literal-declarations 
(Specifically, LITERAL 
is permitted, but 
GLOBAL LITERAL is not) 
bind-data-declarations 
(only if data-name-value 
is ctce) 

bind-routine-declarations 
(only if routine-name-value 
is ctce) 

compiletime-declarations 

macro-declarations 

keyword-macro-declarations 

require-declarations 

library-declarations 

switches-declarations 

undeclare-declarations 

builtin-declarations 



(Chapter 10) 
(Chapter 11) 

(Chapter 12) 
(Chapter 13) 
(Chapter 14) 



(Chapters 15 and 16) 



(Chapter 18) 



16.6.3 Semantics 

The declarations encoded in the specified library binary file are incorporated 
into the module being compiled. More precisely, the following actions are 
performed: 

1. Locate the file specified by the file-designator. File name default rules 
are described in the appropriate BLISS user's guide. 

2. Verify that the specified file is a library binary file and that the com- 
piler that generated the file is compatible with the compiler that is 
compiling the library-declaration. 

3. Add the precompiled tables that make up the specified file to the tables 
already formed by the compiler. 

The result is to establish a set of declarations with a minimum of compiler 
activity. 

Switches-declarations in the library source file affect the precompilation of 
the file but have no effect on the module that uses the file in a library- 
declaration. 
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Lexical-expressions are expanded at the time a library source file is compiled 
to produce the library binary file, not when the library binary file is incorpo- 
rated into another module. 

The undeclare-declaration can be used at the end of a library source file to 
prevent declarations from being output to the library binary file. In this way, 
the effect of a declaration can be confined to the compilation of the library file 
itself. This approach is essential when the same name is declared in several 
library files that are used together in the same module. 

Observe that a library source file can include both a require-declaration and a 
library-declaration. 

Library declarations are permitted in a library precompilation to allow data- 
structuring packages (such as XPORT) to be used both in library construction 
and within any individual modules that refer to the library. 

All symbols defined by the nested library, will be implicitly undeclared at the 
end of precompilation; this prevents the generation of error messages due to 
names being declared in two libraries. However, if it is necessary to retain the 
symbols from the declared library, the library can be referenced by a require- 
declaration using the source file as file-designator. 

As an example, assume library COMLIB is being built to contain a common 
set of data structures for a project; moreover, the structures use XPORT 
$FIELD macros, while the project uses the XPORT I/O package. Thus, 
COMLIB. REQ will contain lines such as: 

LIBRARY 'SYS$LIBRARY: XPORT ' i 



$FIELD 




LINKED _LIST 




SET 




NEXT = 


[$ADDRESS] 


LAST = 


C$ADDRESS3 


YALU = 


[$INTEGER] 


TES ; 





When COMLIB.REQ is being precompiled, the $FIELD, $ADDRESS, and 
$INTEGER definitions are defined by the XPORT library; however, at the 
end of the precompilation process the definitions are deleted. 

When a module that uses XPORT I/O is compiled it can contain the following 
lines: 

LIBRARY 'SYS$LIBRARY:XPORT ' 5 
LIBRARY 'LIB$:COMLIB ' ; 



Note that if the COMLIB library contained a macro declaration such as: 

MACRO DOLLAR_FIELD = $FIELD 7,5 

The macro would not be expanded at declaration time and $FIELD would be 
unbound. Thus, if a source module (that did not have a library XPORT 
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declaration) referenced the DOLLAR FIELD macro, $FIELD would be 

treated as an undefined name. 

Another example of a library-declaration within a library compilation follows. 
This example emphasizes the sometimes unexpected behavior that can occur 
during the compilation of nested libraries. 

For the example, assume that two files are separately compiled as follows: 

$ BLISS/LIBRARY INNER 
$ BLISS/LIBRARY OUTER 

The first compilation produces INNER. L32 as follows: 



) o 1 

) 2 
) 3 
) 4 
)05 



FIELD 

CAB_FIELDS = 
SET 

CAB$W_BLN 
TES i 



C 1 



,31 



The second compilation produces OUTER. L32 as follows: 



LIBRARY " INNER" ; 

EXTERNAL ZOT : BLOCK [ 1 00 ] F I ELD ( CAB_F I ELDS ) \ 



1 
2 
3 
WARN 201 

Illegal occurrence of bound name C A B _ F I E L D S in library source 
in o d u 1 e 

The error message occurs because symbols from the INNER library are not 
included in the OUTER library. The symbol ZOT, declared in the OUTER 

library, refers to the symbol CAB FIELDS, declared in the INNER library; 

if, in a subsequent compilation, the OUTER library is used without the 
INNER library the declaration of CAB_FIELDS will not be available. 
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Chapter 17 
Condition Handling 



Condition handling is the response to an unusual event that is signaled during 
execution of a program. The "unusual" event is often the detection of an 
error, but need not be; it could for example be part of a scheme to measure the 
performance of a program. This chapter describes the features of BLISS that 
support condition handling. 

Condition handling involves the BLISS language together with the target 
hardware and software system. For additional system details, see the respec- 
tive hardware and operating system reference manuals, as well as the respec- 
tive BLISS User's Guides. 

17.1 Introduction to Condition Handling 

Condition handling begins when an event or situation is signaled by a call on 

one of the executable-functions SIGNAL or SIGNAL STOP. The signal is 

directed to a part of the system called the Condition Handling Facility 
(CHF). The CHF retains control until the unusual event has been dealt with; 
but the CHF can, and usually does, call upon user routines for assistance. 
Then, depending on the outcome, program execution continues or is termi- 
nated. 

17.1.1 Routines 

Condition handling involves the interaction of three kinds of routines. First is 
a signaler routine, which contains code that generates the signal, either expli- 
citly or implicitily. Second are handler routines, which are called upon by the 
CHF to provide the desired response to a signal. Third are establisher routines 
that contain a special declaration, the enable-declaration, that associates a 
handler routine with the establisher routine. 

The three kinds of routines just described are not new kinds of routines; they 
are routines that are used in a new way, to play special roles in condition 
handling. A single routine can play two or three of these roles at the same 
time; in fact, a routine can even establish itself as its own condition handler. 
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Furthermore, a single routine can be used in many places; for example, a 
single routine can be established as the handler routine by many establisher 
routines. 

17.1.2 Signals 

A signal can be generated in three ways. First, a signal can be explicitly 

generated by a call on the executable -function SIGNAL or SIGNAL STOP. 

Second, a signal can be implicitly generated by the hardware or the software 
system as a result of a condition detected during program execution. Third, a 
special kind of signal, the unwind signal, can be indirectly generated by a 
handler routine by means of a call on the executable-function SETUNWIND. 

When a signal is generated, a data segment termed the signal vector is used to 
describe the condition. This vector contains a condition value, which is an 
encoding of the primary description of the condition that caused the signal. 
The encoding of the condition value is defined by software conventions and is 
the same for all conditions. The remaining elements of the signal vector pro- 
vide suplementary information about the condition; this information can vary 
from one condition to another. 

17.1.3 Processing 

When condition handling is initiated, the CHF searches the stack of routine 
calls for the most recently established handler. The handler is called by the 
CHF with three parameters giving, respectively, values from the signaler (one 
of which is a condition value), values from the CHF itself, and values from the 
establisher of the handler. The handler uses this information to determine 
what action to take in response to the condition. 

The handler indicates to the CHF how condition handling for the signal 
should proceed after the handler returns to the CHF. In the simplest case, the 
handler requests the CHF to return to the signaler. This completes condition 
handling for that signal. 

The handler can also request resignaling. In this case, CHF searches for the 
next handler in the stack of routine calls and calls it. The search for and 
calling of successive handlers continues as long as each handler in turn re- 
quests resignaling. 

Finally, the handler can request unwinding. Unwinding causes the execution 
of various routines to be terminated by removing each routine's stack frame 
from the stack of routine calls as though the routine had returned normally. 

During unwinding, the handler of any routine that is being terminated is 
called (a second time) to give each handler an opportunity to perform any 
actions necessary on behalf of the establisher in order for the establisher to 
complete properly. Examples of such actions are closing files opened by the 
establisher, releasing dynamically allocated storage, adjusting counters and 
flags, and so on. Normal execution resumes after the call to the establisher of 
the handler that requested unwinding. This completes condition handling for 
that signal. 
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The description of condition handling is given in five parts. The first three 
parts present the BLISS language features relevant to the three kinds of 
routines involved in condition handling. First, enable-declarations, used in 
establisher routines, are described. Second, signals and the means by which a 
signaler routine initiates condition handling are described. Third, handler 
routines, their parameters and the means by which a handler directs CHF 
processing are described. The fourth part describes the flow of control during 
condition handling among the three kinds of routines. The fifth part gives 
examples of the application of condition handling. 



17.2 Enable-Declarations 



An enable-declaration is the means by which one routine, an establisher, 
identifies another routine as a handler routine. The association is established 
at the beginning of the establisher's execution and lasts throughout the execu- 
tion of that routine and any routines that it calls. The association is automati- 
cally broken when the establisher routine returns. 

In addition to specifying the handler routine, the establisher may also specify 
parameters that will be passed to the handler when, and if, the handler is 
actually called. The following example illustrates this: 



ROUTINE X(Y »Z) = 


BEGIN 


EXTERNAL ROUTINE 


XH5 


LOCAL 


L: volatile; 


ENABLE 


XH(L) ; 


♦ ♦ + 

end; 



Routine X establishes the routine XH as its handler and specifies the address 
of a local data segment, L, to be passed to the handler when the handler is 
called. 



17.2.1 Syntax 



enable- 
declaration 


ENABLE routine-name 

( ( enable-actual ,... ) ) 
( nothing J 


enable-actual 


/ own-name \ 
1 global-name 1 
I forward-name | 
V local-name / 


routine-name \ 
own-name / 
global-name .> 
forward-name 1 
local-name ' 


name 
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17.2.2 Restrictions 

An enable-declaration must appear only in the outermost block of a routine- 
definition. 

Only one enable-declaration can appear in the outermost block of a routine- 
definition. (This does not prohibit a nested routine, as well as the outer 
routine, from containing an enable-declaration.) 

In BLISS-16 and BLISS-32, a routine that contains an enable-declaration 
must be declared with a linkage-attribute that is itself declared with a link- 
age-type as follows: the JSR linkage-type in BLISS-16, or the CALL link- 
age-type in BLISS-32; observe that the predeclared default linkage satisfies 
this restriction in each case. Further, no EXTERNAL REGISTERS or output- 
registers are permitted. 

The routine-name given in an enable-declaration must be the name of a 
routine declared in a routine- or bind-routine-declaration. 

In BLISS-16 and BLISS-32, the linkage-attribute of the handler routine- 
name given in the enable-declaration must be the predefined linkage-attri- 
bute BLISS. 

Each data segment name that appears as an enable-actual parameter in an 
enable-declaration must have the volatile-attribute specified in its declara- 
tion. 

If the handler routine can potentially modify any data segment other than an 
enable-actual data segment (for example, a data segment whose address is 
given by the contents of an enable-actual parameter), that data segment must 
be declared with the volatile-attribute. 



17.2.3 Semantics 

The enable-declaration establishes a given routine as the routine to handle 
any software- or hardware-detected conditions that are signaled during the 
execution of the routine containing the enable-declaration. The execution of 
the establisher includes the execution of any routines that it calls, directly or 
indirectly. However, it may or may not include the execution of any handlers 
as described in Condition Handling Flow of Control (see Section 17.5). 

The enable-actual parameters given in the declaration are the names of data 
segments whose address values are passed to the handler when and if it is 
called. 

An enable-actual parameter can be the name of a local data segment (de- 
clared LOCAL or STACKLOCAL) and if so, that data segment is implicitly 
initialized to all zero bits before the handler routine is established. 

The enable-declaration does not, of itself, call the given handler routine. 
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17.3 Signaling 



Signaling initiates condition handling and thereby indicates that a particular 
event or condition has occurred. A signal can be explicitly generated by call- 
ing one of the executable-functions SIGNAL or SIGNAL STOP, can be 

implicitly generated by hardware detected error conditions (such as an access 
violation or arithmetic overflow) and can be indirectly generated by a handler 
routine request for unwinding. 

All signals identify a condition by means of a vector that contains a condition 
value. The vector can also contain additional values that provide auxiliary 
information about the condition. 



17.3.1 Condition Values 

A condition value is a single fullword value that encodes the identity and 
severity of the condition. The severity field is encoded in the low-order three 
bits and the identity field in the remaining high-order bits. In BLISS-16, the 
identity field consists of all 13 of the high order bits of the 16-bit word. In 
BLISS-32 the identity field consists of the next 25 bits (above the severity 
field), and in BLISS-36 consists of the next 29 bits, leaving the high-order 
four bits for other purposes in both dialects. 

When accessing a condition value to determine which condition is being re- 
ported, it is necessary to examine only the identity field, excluding the re- 
mainder. The same condition identity value may be signaled with different 
severity values at different times. 

A more detailed description of condition value representation is given in Sec- 
tion 17.6.1, along with example declarations for conveniently creating and 
accessing condition values. 

17.3.2 Explicit Signals 

BLISS programs can explicitly generate a signal by calling one of the execut- 
able-functions SIGNAL or SIGNAL_STOP. These functions are defined as 
follows: 

SIGNAL( condition-value ) 

SIGNAL( condition-value , parameter ,... ) 

Initiates condition handling for the condition indicated by the given 
condition- value. If parameters are given in addition to the condition- 
value, these values are included in the signal vector (see Section 17.4.2.1) 
passed to each handler that is called. 

The function returns if and only if a handler for the condition requests 
continuation. (In BLISS-32, the VAX/VMS system establishes a default 
"catch-all" handler for all signals; see Section 17.6.4.2.) 
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The function returns a value if and only if a handler assigns a returned- 
value to the mechanism vector (see Section 17.4.2.2); otherwise, the 
value is undefined. 

SIGNAL_STOP( condition-value ) 

SIGNAL STOP( condition-value , parameter ,... ) 

Initiates condition handling for the condition indicated by the given 
condition- value. A condition-value with the severity field replaced by the 
code for severe error (STS$K__SEVERE, see Section 17.6.1) is included 
in the signal vector passed to each handler that is called. If parameters 
are given in addition to the condition-value, these values are also in- 
cluded in the signal vector passed to each handler. 

The function does not return. 

SIGNAL and SIGNAL STOP are identical in their actions, with two excep- 
tions. First, if SIGNAL is called control may eventually return to the caller 

depending on the actions of the handler, while if SIGNAL STOP is called 

control will not return to the caller. Second, the condition-value of a SIG- 
NAL STOP call is changed to indicate severe error while the condition-value 

of a SIGNAL call is used without modification. 

Information can be returned from a handler to a signaler if the signaler in- 
cludes a parameter in the call to SIGNAL that gives the address of a data 
segment where the information should be assigned by the handler. 

17.3.3 Implicit Signals 

Signals may be generated by the system in response to a hardware detected 
condition or an operating system detected condition. For hardware conditions, 
the system uses the information available from the hardware and simulates a 
call to SIGNAL as though SIGNAL were called at the instruction that caused 
the error (either before or after the instruction, depending on the target sys- 
tem and the type of hardware condition) . Thereafter, processing is the same 
as for explicitly generated signals. 

17.3.4 Unwind Signals 

The handler of a condition may cause the routine that generated a signal to be 
terminated. In fact, many routines may be terminated in this "abnormal" 
way, termed unwinding. During unwinding, the handler of each routine that is 
being terminated is called with a condition value indicating that the estab- 
lisher routine is being terminated. This particular condition is termed the 
unwind signal and some special rules apply. 

Unwind signals are further discussed in the next section. 

17.4 Condition Handling Routines 

A condition handling routine is a routine that is declared by some other 
routine to be a handler. The purpose of a condition handling routine is to 
accept and deal appropriately with some set of signaled conditions that may 
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occur during the execution of the establishes In nearly all respects, a handler 
routine is like any other routine: it can call other routines, call the operating 
system for service, and so on. It can establish a handler for itself and in some 
cases that handler might even be itself. 

A handler is special in that it is called in response to conditions that are 
signaled by other routines. It is unlikely that a routine coded for use as a 
handler would ever be called directly. Because handlers are called by system 
software, and not directly by user written calls, they must conform to system 
defined restrictions and conventions. 

A handler is called by the CHF with three actual parameters. The first pa- 
rameter is the address of a vector, termed the signal vector, that contains the 
parameter values specified in the call to SIGNAL or SIGNAL_STOP that 
generated the signal. (In BLISS-32, additional values are supplied as well.) 
The second parameter is the address of a (second) vector, termed the mecha- 
nism vector, that contains values provided by the CHF software. The third 
parameter is the address of a (third) vector, termed the enable vector, that 
contains the enable-actual parameter values specified in the enable-declara- 
tion of the routine that established the handler. Thus, a handler has available 
information from both the routine generating the signal and the routine that 
established the handler, as well as certain system information, to determine 
how to deal with the condition. 

A handler is called as a result of every signal that occurs during the execution 
of its establisher and that is not dealt with by another handler. The first 
responsibility of every handler is to examine the condition value of each signal 
to determine whether the signal is to be dealt with at all. It is quite unusual 
for a specific handler to be relevant to every possible signal that can occur. 

If a signal is not the unwind signal, a handler must request the CHF to further 
process the signal in one of the following ways: 

• Continue the routine that generated the signal. 

• Resignal the same, or possibly a modified, signal to some other handler. 

• Unwind. 

The next three sections discuss condition handling routines in detail. The first 
specifies the restrictions that must be met by every handler routine. The 
second describes the parameters to a handler routine. The third specifies how 
a handler routine requests each of the three options. 

17.4.1 Restrictions 

In BLISS-16 and BLISS-32, a condition handling routine must be declared 
with the predeclared linkage-attribute BLISS (see Section 13.5). Observe that 
this will be the default unless another default is established by a LINKAGE 
switch-item (see Section 18.2) or module-switch (see Section 19.2). 

A condition handling routine must be declared with three formal parameters. 

A condition handling routine must not have the NOVALUE attribute unless 
it always requests unwinding for every signal. 
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A condition handling routine must fetch from or assign to only data segments 
that satisfy one of the following requirements: 

• A data segment whose scope is limited to the body of the condition 
handling routine itself. 

• An element of one of the vectors whose addresses are passed to the han- 
dler as parameters. 

• Any data segment that is declared with the volatile-attribute. 

17.4.2 Parameters 

A condition handling routine is called with three parameters. Each parameter 
is the address of a counted vector containing the relevant information. A 
counted vector is a vector of fullwords in which the first element (with index 
value 0) contains the number of additional elements in the vector. The first 
element is always present and contains the value if there are no additional 
elements in the vector. 

The following BLISS code fragment shows a template for the declaration of a 
handler routine. This template is used in the remainder of this section in the 
discussion of each parameter of a handler routine. The template is: 

ROUTINE HANDLER(SIG . MECH > ENBL) = 
BEGIN 
MAP 

SIG: REF VECTOR* ! Si anal vector 
MECH: REF '.'ECTOR* ! Mechanism vector 
ENBL: REF VECTOR; ! Enable sector 
BIND 

COND = SIGCU: CONDITION-VALUE* 
RETURN-VALUE - MECH 
C 

7.BLISS1G( 1 ) 
7.BLISS3G( 1 ) 
7,BLISS32(3) 
] ; 

END ; 

In this template, the map-declaration (see Section 10.10) associates the REF 
VECTOR structure-attribute (see Section 11.9.1) with each of the routine 
formal names for convenient referencing of each vector whose address is 
passed to the handler. The bind-declaration (see Section 14.3) defines mne- 
monic names to two of the most commonly accessed elements of the passed 

vectors. CONDITION VALUE is the name of a macro whose expansion 

gives the attributes appropriate for accessing a condition value. Its definition 
is presented in Section 17.6.1. The predeclared macros %BLISS16, 
%BLISS32, and %BLISS36 are described in Section 16.2.4. 

17.4.2.1 The Signal Parameter — The first parameter, SIG, contains the 
address of a signal vector, which is a counted vector that contains the value(s) 
of the actual parameters of the call to SIGNAL or SIGNAL_STOP. In 
BLISS-32, the CHF adds two values following those given in the SIGNAL or 
SIGNAL STOP call: the hardware program counter (PC) and the program 
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status longword (PSL) of the next instruction to execute in the case that the 
handler requests continuation of the signaler. In the context of the above 
template: 

.SIG[n] is the n'th actual parameter value, where, in particular 

.SIG[1] is the condition value, 

.SIG[0] is the number of actual parameters, and 

COND is the address of the condition value. 

For explicit signals, the actual parameter values are given by the parameters 
of the call to SIGNAL or SIGNAL—STOP . 

For implicit signals and the unwind signal, the actual parameter values are 
defined by the system. These values and their encodings are not described in 
this manual. 

17.4.2.2 The Mechanism Parameter — The second parameter, MECH, con- 
tains the address of a mechanism vector, which is a counted vector that 
contains the values of parameters provided by the CHF. These values provide 
specialized software status information about the signal being processed. Of 
the several values that may be present, only one is described in this manual. 

The element of the mechanism vector with address 

MECH[1] in BLISS-16 and BLISS-36, or 
MECH[3] in BLISS-32 

in the preceding template, is a data segment to which a handler routine can 
assign a value to be used as a returned-value. A handler can assign a value to 
this location in two situations. 

When a handler requests continuation of the signaler routine, the CHF uses 
the contents of this location as the return value of the SIGNAL call. By 
assigning to this location, the handler can determine the return value. If the 
handler does not assign to this location, the returned value is undefined. 

After unwind processing, the CHF uses the contents of the return value loca- 
tion in the mechanism vector as the return value of the last routine to be 
terminated. By assigning to this location, the handler can determine the 
establisher's return value. By this means, the establisher routine returns a 
meaningful value to its caller even though it is terminated by the CHF. A 
handler for any establisher that returns a value (that is, does not have the 
NOVALUE attribute) must assign an appropriate return value to the return 
value location in the mechanism vector during unwinding. 

17.4.2.3 The Enable Parameter — The third parameter, ENBL, contains the 
address of an enable vector, which is a counted vector that contains the values 
of the enable-actual parameters of the ENABLE declaration of the establisher 
routine. In the context of the earlier template, the expression 

.ENBL[n] is the n'th enable-actual parameter value, and 

.ENBL[0] is the number of enable-actual parameters. 
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The enable-declaration requires that each enable-actual parameter must be 
the address of a data segment. Consequently, within the handler routine it 
may frequently be convenient to bind (Section 14.3) mnemonic names to 
these address values, as in: 

BIND 

PARAM1 = .ENBLC 1 ] » 
XYZZY = . ENBLH2] ? 

Enable-actual parameters can be the names of local data segments declared 
in the establisher routine. If a recursive routine establishes a handler, the 
same handler will be used for all active calls of the recursive routine. If the 
handler is called and resignals the condition, the same handler is repeatedly 
called for each active call of the establisher routine. In each case, the address 
of a local data segment name passed to the handler is the appropriate address 
in the respective active call of the establisher. 

17.4.3 Handler Options 

For every condition other than the unwind signal, a handler must request one 
of three subsequent actions for the CHF to perform after the handler returns. 

1. The handler can deal appropriately with the condition and then cause 
the routine that initiated the signal to continue. 

Continuing the routine that initiated the signal completes processing of 
the condition. 

2. The handler can resignal using the same, or possibly a modified, condi- 
tion value. 

Resignaling with the same condition value is the normal response for a 
condition that the handler does not deal with. Resignaling causes the 
CHF to resume searching for a handler that will deal with the condition. 

3. The handler can deal appropriately with the condition and then termi- 
nate the execution of the routine that generated the signal as well as the 
other routines called by the establisher by unwinding. 

Unwinding causes a special unwind signal to be generated. The han- 
dlers of all routines that are being terminated will be called with this 
condition. Unwinding also completes processing of the condition. 

These options are not available when a handler is called for the unwind signal. 

The means of requesting these actions are presented in the following sections. 

17.4.3.1 Continuation — A handler requests continuation of the routine that 
generated the signal by returning a true value (low bit set to 1) to the CHF. 
The handler must not also call SETUNWIND, as described in Section 
17.4.3.3. 
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After the handler returns to the CHF, the CHF returns from the call to I 
SIGNAL in the routine that generated the signal. 

A handler must not request continuation for a signal that was generated by 

calling SIGNAL STOP. That is, a handler must not request continuation if 

the severity field of the condition-value indicates severe error. 

17.4.3.2 Resignaling — A handler requests resignaling by returning a false 
value (low bit set to 0) to the CHF. The handler must not also call 
SETUNWIND, as described in 17.4.3.3. 

After the handler returns to the CHF, the CHF searches for another handler I 
routine to call as described in Section 17.5. 

When resignaling is requested, the same signal vector is passed to subsequent 
condition handlers that are called. Thus, the severity and/or the condition 
identification can be changed by the handler by assigning new values to the 
condition value element of the signal vector. If condition handling is initiated 

by a SIGNAL STOP call, however, the severity field is set to severe error by 

the CHF each time a handler is called. Consequently, the severity field cannot 
be changed by a handler in this case. 

Changing the condition value and resignaling is quite different than generat- 
ing a new signal by calling SIGNAL or SIGNAL—STOP in the handler. In the 
latter case, processing of the first signal is suspended until processing of the 
second signal is completed; then processing of the first signal resumes. 

17.4.3.3 Unwinding — A handler requests unwinding by calling the execut- 
able-function SETUNWIND. The function is defined as follows: 

SETUNWIND( ) 

SETUNWIND( parameter ) <= 32 Only 

SETUNWIND( parameter , parameter ) <= 32 Only 

Requests the CHF to initiate unwind processing after the currently exe- I 
cuting handler returns to the CHF. (In BLISS-32, the two optional I 
parameters can be used to specify the routine level at which the unwind 
will stop and the address where normal execution is to resume. These 
parameters are not described in this manual.) The function does not 
return a value in BLISS-16 or BLISS-36, and returns a VAX/VMS de- 
fined status value in BLISS-32". 

When a handler requests unwinding the returned-value of the handler is 
ignored. 

The handler specifies the value to be used as the returned-value of the 
establisher by assigning the appropriate value in the mechanism parame- 
ter vector (see Section 17.4.2.2.) when the handler is called for the 
unwind signal. 
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In the default case, that is, when no parameters are given in the call to 
SETUNWIND, all routines between and including the routine that gen- 
erated the signal and the establisher of the handler are terminated. Exe- 
cution resumes after the call to the establisher as though the establisher 
had returned in the normal way. 

Unwinding does not start immediately when SETUNWIND is called. The call 
simply advises the CHF that unwinding is requested. When the handler even- 
tually returns to the CHF, unwinding begins. 

During unwind processing, the handler, if any, of each routine being termi- 
nated is called with a condition value indicating an unwind is in progress. In 
the default case, where the establisher is one of the routines being terminated, 
the handler requesting the unwind will itself be called a second time to pro- 
cess the unwind signal. 

A condition handling routine can call other routines as part of its processing 
and the request for unwinding can be made from any such routine. The call to 
SETUNWIND need not be made in the topmost routine directly called by the 
CHF. 

It is invalid to request unwinding in any of the following cases: 

• Condition handling is not in progress. 

• An unwind request has already been made. 

• Unwind signal processing is in progress. 

17.5 Condition Handling Flow of Control 

Condition handling flow of control refers to the order in which condition 
handling routines are called during condition handling. The order is defined 
in terms of the stack of routine calls that are active at the time a signal is 
generated in combination with subsequent handler requests. 

17.5.1 Definition 

The definition of condition handling flow of control is given in two parts. The 
first defines the flow of control for a signal that is generated when condition 
handling is not in progress. The second defines the modified flow of control 
that results for a signal that is generated while condition handling for a 
previous signal is still in progress. 

17.5.1.1 Normal Flow of Control — The generation of a signal begins a se- 
quence of events that is carried out under the control of the CHF. 

First, the CHF creates the signal vector and mechanism vector for use in 
calling a handler. If the signal is generated by a SIGNAL STOP call, the 
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severity field of the condition value in the signal vector is assigned the code for 
severe error. 

Next, the stack of routine calls is searched, beginning with the routine that 
generated the signal. If that routine did not establish a handler, then the 
routine that called it is considered and so on, until the most recently called 
routine is found that did establish a handler. This handler is called with three 
parameters as described in Section 17.4.2. 

Following the return from the handler, processing depends upon which option 
is requested by the handler. 

If continuation is requested, then the CHF returns to the signaler and condi- 
tion handling for that signal is completed. 

If resignaling is requested, then the CHF continues searching the stack prior 
to the establisher of the handler just called. If another handler is found, then 
it is called in the same way as the previous handler. This process of searching 
for and calling successive handlers continues as long as each handler requests 
resignaling. If every handler indicates resignaling, that is, no handler is found 
that causes completion of the signal, then system defined error processing 
takes place. 

In BLISS-16, if no handler is found the program exits. In BLISS-36, if no 
handler is found a message is displayed on the user's terminal and the pro- 
gram exits. 

In BLISS-32, the VAX/VMS system establishes a "catch-all" handler to pro- 
vide default handling for all signals. Consequently, this handler will be called 
if no user handler is found or if every user handler requests resignaling. The 
action of this handler is described in Section 17.6.4.2. 

If unwinding is requested, then the handler just called and its establisher are 
remembered and a new search is started. This search starts over at the sig- 
naler routine just as in the first search. This time, however, each routine is 
terminated by removing its stack frame from the stack of routine calls. If the 
routine has a handler, the routine is terminated after the handler is called 
with a condition value that indicates that unwinding is in progress. The 
handler does not have the three options that are available during the first 
search: SETUNWIND must not be called and the value of the handler is 
ignored. This second search completes after the handler that initiated 
unwinding is called the second time. When that handler returns, the estab- 
lisher is terminated and normal execution resumes immediately following the 
call to the establisher. 

17.5.1.2 Modified Flow of Control for Nested Signals — A nested signal is a 
signal that is generated while condition handling for a previous signal is in 
progress. A nested signal occurs, for example, if a handler routine calls SIG- 
NAL. When a nested signal is generated, condition handling for the previous 
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signal is suspended until condition handling for the nested signal is com- 
pleted. Then processing resumes for the previous signal. 

Processing of a nested signal is the same as for a non-nested signal with one 
exception: the search for handlers is modified to exclude any handlers that 
have been called for the previous signal. Observe that the handler that is 
active when the nested signal is generated is excluded by this rule. However, 
this handler can itself have a handler and if so, this (second) handler is 
included in the modified search. 

If the handler of a previous signal is terminated (so that it cannot request 
CHF processing) because of an unwind request for a nested signal, then all of 
the routines considered during condition handling of the previous signal are 
also terminated. The handlers of the combined set of routines being termi- 
nated are all called with the unwind signal in the inverse order to which they 
were established. Observe that more than one previous signal can be affected 
in this way. Completion of unwinding completes condition handling for all of 
the affected signals. 

17.5.2 Discussion 

Several aspects of condition handling flow of control are discussed. First, 
examples of the detailed sequence of events are illustrated. Second, recursive 
handlers are considered. Finally, interactions between condition handling and 
routine linkages are discussed. 

17.5.2.1 Examples of Flow of Control — Example sequences of flow of control 
during signal processing are illustrated using the following diagram: 

\ 
A 

\ 
B BH 

\ \ 

C CH F 

\ \ \ 

D E SETUNWIND 

\ 
SIGNAL 

In this diagram, a diagonal line indicates that the upper routine calls the 
lower routine, e.g., A calls B, B calls C, and so on. A horizontal line indicates 
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that the left routine establishes the right routine as a handler, e.g., routine C 
establishes routine CH as its handler. 

The example begins by assuming that routine A is executing, that is, A has 
been called by some other routine not shown in the diagram. 

Routine A does not establish a handler. At some point in its execution A calls 
routine B. B establishes routine BH as a handler; BH is not called when it is 
established. B calls routine C. Routine C establishes handler CH and then 
calls D. D does not establish a handler but does generate a signal. 

At this point the stack of routine calls consists of A, B, C and D with D being 
the most recently called (the call to SIGNAL does not count). Routines B and 
C have established handlers, but A and D do not. 

The CHF searches for a handler. First routine D is considered, but no handler 
is established. Next, routine C is considered. A handler is established and, 
thus, CH is called. CH calls another routine E which returns to CH which 
returns to the CHF. What happens next depends on the option requested by 
CH. 

First, suppose that CH requests continuation. In this case, the CHF returns 
to D and D continues. The complete sequence of events is summarized as 
follows: 

A calls B 

B establishes handler BH 

B calls C 

C establishes handler CH 

C calls D 

D calls SIGNAL 

CHF calls CH 

CH calls E 

E returns to CH 

CH returns to CHF requesting continuation 

CHF returns to D 

D continues 

Next, suppose that CH requests resignaling (instead of continuation). In this 
case, the CHF continues searching for a handler by considering routine B. B 
has a handler, and, thus, BH is called. BH calls F and F calls SETUNWIND. 
The CHF records the fact that an unwind is requested and returns to F. F 
returns to BH and BH returns to CHF. The value of BH is not used by CHF 
because unwinding has been requested. At this point, the second search 
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starts. D does not have a handler and is terminated. CHF calls CH which 
returns to CHF. C is terminated. CHF calls BH which returns to CHF. This 
completes the second search. B is terminated. Finally, CHF "returns" to A 
using the returned-value obtained from the mechanism vector as though B 
had returned in normal fashion and A continues. 

The sequence of events is summarized as follows (the first nine events are the 
same as the preceeding summary): 

A calls B 

B establishes handler BH 

B calls C 

C establishes handler CH 

C calls D 

D calls SIGNAL 

CHF calls CH 

CH calls E 

E returns to CH 

CH returns to CHF requesting resignaling 

CHF calls BH 

BH calls F 

F calls SETUNWIND 

CHF records the unwind request 

CHF returns to F 

F returns to BH 

BH returns to CHF 

D is terminated 

CHF calls CH with the unwind signal 

CH returns to CHF 

C is terminated 

CHF calls BH with the unwind signal 

BH returns to CHF 

B is terminated 

CHF "returns" to A as though B had returned 

A continues 

Observe in this example that handler BH must assign the return value of B for 
the call from A when BH is called for the unwind signal. If BH assigned the 
return value the first time it was called, there is the possibility that some 
other handler, such as CH in this example, will assign a return value when it 
is called with the unwind signal. Thus, the returned value intended by BH 
would be lost. 
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For an example of nested signal processing, the following diagram is used: 

\ 
A AH 

\ 
B BH BHH 

\ \ ■ 
C D DH 

\ \ 

SIGNAL SIGNAL 

The initial sequence of events is apparent from the previous examples and is 
summarized by: 

A establishes handler AH 

A calls B 

B establishes handler BH 

B calls C 

C calls SIGNAL 

CHF calls BH 

BH establishes handler BHH 

BH calls D 

D establishes handler DH 

At this point D generates a nested signal. The modified search in this case 
considers, as potential establishers, only routines D, BH, A and so on. 
Routines C and B are excluded from consideration. Assume that DH and 
BHH request resignaling and AH requests continuation. Events proceed as 
follows: 

D calls SIGNAL 

CHF calls DH 

DH returns to CHF requesting resignaling 

CHF calls BHH 

BHH returns to CHF requesting resignaling 

CHF calls AH 

AH returns to CHF requesting continuation 

CHF returns to D 

At this point processing of the nested signal is complete and processing of the 
first signal resumes. The subsequent sequence of events is apparent and not 
filled out here. 

As a final possibility, assume that for the nested signal just illustrated that 
DH and BHH request resignaling (as before) and AH requests unwinding 
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(instead of continuation). In this case, control will not return to D or BH 
because they will be terminated. Consequently, BH cannot request an option 
for the first signal. Processing of the first signal must, consequently, be termi- 
nated as well. In effect, the unwind requested by AH for the nested signal also 
applies to the previous signal. (This can apply to yet a third signal if the 
previous signal was itself a nested signal, and so on.) The second search of the 
stack considers all of the routines that are being terminated including those so 
far considered by the first signal. Jn this example, the order of consideration is 
D, BH, C, B and A. Events proceed as follows (starting when AH is called): 

AH calls SETUNWIND 

CHF records unwind request 

CHF returns to AH 

AH returns to CHF 

CHF calls DH with the unwind signal 

DH returns to CHF 

D is terminated 

CHF calls BHH with the unwind signal 

BHH returns to CHF 

BH is terminated 

C is terminated 

CHF calls BH with the unwind signal 

BH returns to CHF 

B is terminated 

CHF calls AH with the unwind signal 

AH returns to CHF 

A is terminated 

CHF "returns" to A's caller (not shown) 

A's caller continues 

17.5.2.2 Recursive Handlers — A recursive handler routine is a handler rou- 
tine that establishes itself as a handler or that calls (directly or indirectly) 
another routine that establishes it as a handler. Consequently, it is possible 
during the execution of such a handler that it will be recursively called to 
handle a nested signal. 

Programming a recursive handler can be more difficult than programming a 
non-recursive handler, just as programming any recursive routine can be more 
difficult than a non-recursive routine. It is necessary to carefully consider the 
sequence of events that may result from the combination of the two (or more) 
calls of the same routine. 

Observe that each call of the handler will be caused by a different signal. 
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17.5.2.3 Condition Handling and Linkage Interactions — The flow of control 
during the processing of a signal causes various routines to be called in an 
order that may not be apparent when examining a program. The CHF soft- 
ware depends on calling sequence conventions to assure proper accounting for 
the machine registers and other machine status values during this process. 

The linkage-declaration (see Section 13.3) provides the ability to choose many 
calling sequence variations other than the predefined linkages BLISS and 
FORTRAN. When using such "non-standard" linkages there are various com- 
plex rules and restrictions that must be followed. Some of these would not be 
necessary if condition handling facilities were not part of the BLISS language. 

In BLISS-32, observe that a routine whose linkage-attribute is defined with 
JSB linkage-type must not contain an enable-declaration and must not be 
declared as a handler. Such routines cannot directly interact with the CHF 

software, except to call the functions SIGNAL, SIGNAL STOP, or 

SETUNWIND. 
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The following sections give examples of applying various aspects of condition 
handling. Because condition handling involves the interaction of several 
routines, complete examples are necessarily quite lengthy. The examples 
given below leave out many details in order to be as brief as possible. 

The first section presents declarations that are suitable for accessing and 
creating condition values. Then following sections illustrate applications of 
condition handling. 

17.6.1 Accessing and Defining Condition Values 

Condition values have similar but not identical encodings in BLISS-16 and 
BLISS-32. The following two sections give the encodings used, and declara- 
tions for conveniently accessing and defining condition values, in BLISS-16 
and BLISS-32, respectively. 

17.6.1.1 Condition Values in BLISS-16 — In BLISS-16, a condition value is a 
single fullword value that is encoded with two primary fields: a severity field 
in the low-order 3 bits, and an identity field in the high-order 13 bits. 

The identity field is itself divided into two fields: the condition identification 
field and the customer definition flag. 
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The twelve low-order bits of the identity field (bits 3 through 14 of the condi- 
tion value) are the condition identification field. This field encodes the spe- 
cific condition for the signal. 

The high-order bit of the identity field (bit 15 of the condition value) is the 
customer definition flag. It distinguishes condition identification values for 
Digital supplied software (bit set to 0) and non-Digital supplied software (bit 
set to 1). 

Condition values defined for application use must always have bit 15 set to 1 
in order to avoid conflict with Digital defined values. 

A condition value is a BLOCK data structure (see Section 11.9.3). The follow- 
ing declarations can be used to describe this structure: 

FIELD 

CONDIT_FIELDS = 
SET 

STS*V_SEVERITY 
STS$U_SUCCESS 
STS*V_COND_ID 
STS*V_C0DE 



STS$U_CUST_DEF 
TES 5 



C 1 1 3 1 ] t 
C » » 1 1 ] t 
C 1 3 1 1 3 1 3 * 
[ » 3 1 1 2 1 ] t 

C 1 1 5 » 1 ♦ ] 



Severity field 
Success field 
Identity field 
Code for condition 
only 
Customer definition flag 



MACRO 

C0NDITI0N_i.'ALUE 



BLOCKCU FIELD(CONDIT_FIELDS) 7.5 



The following literal-declaration can be used to declare names for the codes 
used for the severity field of a condition value: 



LITERAL 








STS*K. 


.WARNING 


= t 


Warning 


STS$K. 


.SUCCESS 


= 1 * 


Successful Completion 


STS$K. 


.ERROR 


- 2 t 


Error 


STS$K. 


.INFO 


= 3 t 


Information 


STS$K. 


.SEVERE 


= a ; 


Severe Error 



Observe that these codes are chosen so that testing of the low order bit of the 
severity field will distinguish a successful condition (low bit equal to 1) from 
an unsuccessful condition (low bit equal to 0). 

In the above declarations, the names used are the same as the names used in 
BLISS-32 (see Section 17.6.1.2), which are based on names used in the 
VAX/VMS operating system. 
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As an aid to creating a condition value, the following keyword-macro-declara- 
tion is useful: 

KEYWORDMACRO 

STS*UALUE( 

severity = sts$k_severe t ! default is severe error 
code » ! no default 

cust„def=ii5)= ! default is user definition 

(SEVERITY AND 7) OR 
(CODE AND 7,0 '7777 ' ) - 3 OR 
IF CUST„DEF NEO 

THEN 1 • "■ 1 5 

ELSE 0) 
7.5 

Comparing two condition values to determine if they represent the same 
condition must exclude the severity field. The following macro is useful for 
this purpose: 

MACRO 

STS$MATCH(A »B) = 

(((A) AND 7,0 '177770') EOL ((B) AND 7,0 ' 1 77770 ') ) 7,5 

The macro returns true if two given condition values are equal and false 
otherwise. 

The CHF-defined condition value needed in order to test for an unwind signal 
is provided as a global literal value. The following declaration can be used to 
declare the name of this literal: 

EXTERNAL LITERAL 
SS*UNW» 

17.6.1.2 Condition Values in BLISS-32 — In BLISS-32, a condition value is a 
single fullword value that is encoded with three primary fields (proceeding 
from low-order to high-order): a severity field of three bits, an identity field of 
25 bits, and a field of four bits that is reserved for system use. 

The identity field is itself divided into two major fields: the message number 
field and the facility code field. 

The 13 low-order bits of the identity field (bits 3 through 15 of the condition 
value) are the message number field. This field identifies the specific condi- 
tion for the signal. The high-order bit (bit 15) distinguishes system wide codes 
(bit set to 0) that are common to all software (including user programs) and 
facility specific (component) codes (bit set to 1). 
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The 12 high-order bits of the identity field (bits 16 through 27 of the condition 
value) are the facility code. This field identifies the specific software compo- 
nent in which the signal is generated. The high-order bit (bit 27) distinguishes 
Digital supplied software facilities (bit set to 0) and non-Digital supplied 
facilities (bit set to 1). 

Condition values defined for application use must always have both bits 15 
and 27 set to 1 in order to avoid conflict with Digital defined values. Applica- 
tion programs can use system wide message number values provided they are 
used as defined for the VAX/VMS system. 

A condition value is a BLOCK data structure (see Section 11.9.3). The follow- 
ing declarations can be used to describe this structure: 

FIELD 

C0NDIT_FIELDS = 
SET 

STS$0_SEOERITY 
STS*V. SUCCESS 



STS$U_C0ND_ID 
STS*V_MSG_N0 
STS*Y_FAC_SP 
STS$U_C0DE 

STS*y_FAC_IMO 
STS$0_CUST_.DEF 

TES ; 

MACRO 

CONDITION-VALUE 



E > » 3 > ] » 
C » *1 > ] * 

CO *3 »25 tOl t 
C » 3 f 1 3 » ] » 
C » 1 5 » 1 » ] » 

C » 3 1 1 2 f 3 t 

C 1 1 G 1 1 2 t 3 t 
CO »27 »1 »0 3 



Severity field 
Success field 
(subfield of severity) 
Identity field 
Message number field 
Facility-specific flag 
Code for condition 
only 

Facility code 
Customer 
definition flag 



BLOCKCU FIELD(CONDIT m FIELDS) 1°, 



The following literal-declaration can be used to declare names for the codes 
used for the severity field of a condition value: 



LITERAL 






STS$K„WARNING = 


= t 


! Warning 


STS$K_SUCCESS 


-- 1 t 


! Successful Completion 


STS*K_ERR0R 


-- 2 t 


! Error 


STS$K_INF0 


= 3 f 


! Information 


STS$K_SEUERE - 


= a ; 


! Severe Error 



Observe that these codes are chosen so that testing of the low order bit of the 
severity field will distinguish a successful condition (low bit equal to 1) from 
an unsuccessful condition (low bit equal to 0). 
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As an aid to creating a condition value, the following keyword- macro-declara- 
tion is useful: 



KEYWORDMACRO 

STS$VALUE ( 
SEVERITY 
CODE » 
FACSP = 1 A 15» 



STS*K_SEVERE t 



FAC-ND = 
CUST_DEF 



V t 



1*27) = 
(SEVERITY AND 7) OR 
(CODE AND ( 1 - 13-1 ) ) -3 OR 
( IF FACSP NEQ 
THEN 1-15 
ELSE 0) OR 
(FACNO AND ( 1*12-1 )) "IB OR 
( IF CUST-DEF NEQ 
THEN 1-27 
ELSE 0) 



default is severe error 
no default 
default is facility 
specific 

arbitrary default 
default is user definition 



Comparing two condition values to determine if they represent the same 
condition takes several steps. The following macro serves this purpose: 

MACRO 

STS$MATCH(A »B) = 
BEGIN 
LOCAL 

QQOOA; CONDITION-VALUE t 

OQQOBs CONDITION-VALUE! 
QQQQA = (A) 5 
OOOQB = (B) 5 

IF NOT ( ,QQQQACSTS$V„FAC_SP3 OR ♦ OQQOB C STS$V„FAC_SP ]) 
THEN 

♦ QQQQACSTS$V„CODE] EOL ♦ QOQOB C STS$V_C0DE 1 

L. U D L 

.QQQQACSTS$V„COND_ID] EOL , 00Q0B C STS*V_COND_ I D ] 
END 1i 

This macro returns true if two given condition values are equal and false 
otherwise. 

The CHF-defined condition value needed in order to test for an unwind signal 
is provided as a global literal value. The following declaration can be used to 
declare the name of this literal: 

EXTERNAL LITERAL 
SS$„UNHIND5 

17.6.1.3 Condition Values in BLISS-36 — In BLISS-36, a condition value is a 
single fullword value that is encoded with three primary fields (proceeding 
from low-order to high-order): a severity field of three bits, an identity field of 
29 bits, and a field of four bits that is reserved for future use. 
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(Note that, in the following descriptions, bit positions are expressed in accor- 
dance with the BLISS bit-numbering convention, i.e., bit is the low-order or 
"rightmost" bit and bit 35 is the high-order or "leftmost" bit.) 



The identity field is itself divided into two major fields: 
field and the facility code field. 



the message number 



The 15 low-order bits of the identity field (bits 3 through 17 of the condition 
value) are the message number field. This field identifies the specific condi- 
tion for the signal. Message numbers with the high-order bit (bit 17) clear are 
reserved for Digital supplied software. 

The 14 high-order bits of the identity field (bits 18 through 31 of the condition 
value) are the facility code. This field identifies the specific software compo- 
nent in which the signal is generated. The high-order bit (bit 31) distinguishes 
Digital supplied software facilities (bit set to 0) and non-Digital supplied 
facilities (bit set to 1). 

Condition values defined for application use must always have both bits 17 
and 31 set to 1 in order to avoid conflict with Digital defined values. 

The four high-order bits (bits 32 through 35) are reserved for future use and 
should be set to zero. 

The following declarations may be used to access the various fields of the 
BLISS -36 condition value: 



FIELD 

CONDIT_FIELDS = 
SET 

STS$V_SEVERITY 
STS$V„SUCCESS 

STS$V_COND_ID 
STS$y_MSG_N0 
STS$V_FAC_SP 
STS*V_C0DE 

STS$V„FAC_NQ 
STS*V_CUST_DEF 

TES 5 

MACRO 

CONDITION-VALUE 



C » 1 3 , ] t 
[ > 1 1 1 3 f 

CO »3 »29 »0] » 

C 1 3 * 1 5 1 3 t 
C 1 1 7 1 1 f 3 f 
C 1 3 » 1 a 1 3 t 

C t 1 8 » i a , 3 , 
C ♦ 3 1 > 1 1 3 



Severity field 
Success field 
(subfield of severity) 
Identity field 
Message number field 
Facility specific flag 
Code for condition 

only 
Facility code 
Customer 

definition flag 



BL0CKC13 FIELD(CONDIT_FIELDS) Zi 



The following literal-declaration can be used to declare names for the codes 
used for the severity field of a condition value: 



LIT 


ERAL 










STS$K. 


.WARNING 


= t 


! Warning 




STS$K. 


.SUCCESS 


- 1 t 


! Successful Completion 




STS$K. 


.ERROR 


- 2 t 


! Error 




STS$K„ 


.INFO 


-- 3 


! Information 




STS$K. 


.SEVERE - 


= a 5 


! Severe Error 



17-24 Condition Handling 



Observe that these codes are chosen so that testing of the low order bit of the 
severity field will distinguish a successful condition (low bit equal to 1) from 
an unsuccessful condition (low bit equal to 0). 

As an aid to creating a condition value, the following keyword-macro-declara- 
tion is useful: 



KEYWORDMACRO 

STS$UALUE ( 
SEVERITY 
CODE » 
FAC_SP = 117, 



STS$K_SEVERE 



default is severe error 
no default 
default is facility 

specific 
arbitrary default 
default is user definition 



FAC_N0 = 0» 
CUST_DEF = 1-31) = 

(SEVERITY AND $0 '7 ' ) OR 
(CODE AND 7,0 '37777 ') "3 OR 
( IF FAC_SP NEO 
THEN 117 
ELSE 0) OR 
(FAC_N0 AND 7,0 '37777 ' ) ' 18 OR 
( IF CUST_DEF NEO 
THEN 1 "31 
ELSE 0) 

i; 

Comparing two condition values to determine if they represent the same 
condition takes several steps. The following macro is useful for this purpose: 

MACRO 

STS$MATCH( A »B> = 
BEGIN 
LOCAL 

QQQQA: COND I T I 0N_VALUE » 

QQQQB: CONDITION_UALUE; 
QQQQA = ( A) i 
QQQQB = (B) 5 

IF NOT ( ,QQQQACSTS$V_FAC_SP3 OR ♦ QQQQB C STS*0_FAC SPD) 

THEN 

,QQQQA[STS$V_C0DE3 EQL ♦ QQQQB C STS*Y_ CODE 1 
ELSE 

,QQQQACSTS$V„COND_ID] EQL , QQQQB C STS*0_C0ND_ I D ] 
END 7,5 

The macro returns true if two given condition values are equal and false 
otherwise. 

The CHF-defined condition value needed in order to test for an unwind signal 
is provided as a global literal value. The following declaration can be used to 
declare the name of this literal: 

EXTERNAL LITERAL 
SS$UNW? 



April 1983 
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17.6.2 A Recursive Descent Parser 

A recursive descent parser is a parser in which there is generally a one-to-one 
correspondence between the syntactic rules of the language and routines that 
parse constructs of the language. Each routine is designed to process one 
syntactic name and calls other routines to parse non-literal parts of the syn- 
tactic rule. The BLISS language is an example of a language that is suitable 
for this kind of parsing technique. 

To begin this example, assume tjiat the following two syntactic rules are part 
of a language to be parsed. 



if-statement 



IF expression THEN statement 



expression 



f 



name 

name + expression 

( expression ) 



) 



Further, assume that a routine named READ LEX is available that reads 

the input for the parser, identifies the next lexeme, and assigns a code for the 
kind of lexeme to a data segment named LEXTYPE. (This data segment 
must be declared with the VOLATILE attribute because, as will be seen later, 
its contents may be changed by a handler routine.) The following names of 
lexical codes are used in the example: 



Name of Code 

LE)<_ IF 

LEX-THEN 

LEX_NAME 

LEX_PLUS 

LEX-LPAREN 

LEX-RPAREN 



Used For 

Keyword IF 
Keyword THEN 
A name 

Plus operator "+" 
Left parenthesis "(" 
Right parenthesis ")" 



The actual values for the codes are not important so long as they are distinct. 
A routine to parse an if-statement can be coded as follows: 

ROUTINE SIF: NOMALUE = 
BEGIN 

READ_LEX ( ) 5 
SEXPRESSION( ) i 
IF .LEXTYPE NEC LEX_THEN 
THEN 

BEGIN 

ERROR ( 'Missina THEN ' ) 5 

RETURN 

end; 

READ_LEX ( ) ! 

sstatement( ) 5 
end; 

In this routine, the IF lexeme is recognized by some other parse routine which 
then calls SIF. SIF calls READ LEX to get the next lexeme in the input 
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stream and then calls SEXPRESSION to parse an expression. When SEX- 
PRESSION returns, the code for the first lexeme not accepted as part of an 
expression is still contained in LEXTYPE. Next SIF determines whether that 
lexeme is the keyword THEN. If not, an error is reported and SIF returns. 
Otherwise, READ_LEX is again called to get a new lexeme, SSTATEMENT 
is called to parse a statement, and SIF returns. 

The routine SIF clearly illustrates the close correspondence between the syn- 
tactic rule for the if-statement and the code that performs the parsing. 

The code to parse an expression is more complicated, but is based on the same 
kind of correspondence. However, the name of the routine given next, which 
does the parsing for an expression, is SEXPRESSION1 instead of SEXPRES- 
SION. The reason for this is discussed later. The code is: 

LITERAL 

EXP_ERROR = STS$VALUE<CODE = 1)5 

ROUTINE SEXPRESSIDN1 i NOMALUE = 
BEGIN 

SELECTONE ♦ LEXTYPE OF 
SET 

CLEX_LPAREN] : 
BEGIN 

READ_LEX< ) 5 
SEXPRESSI0N1 ( ) S 
READ_LEX( ) 5 

IF .LEXTYPE NEQ LEX„RPAREN 
THEN 

BEGIN 

ERROR ( 'Miss intf ")"')» 

signal (exp„error) 
end; 
end; 
clex_name] : 

BEGIN 

READ_LEX( ) 5 

IF .LEXTYPE EQL LEX_PLUS 

THEN 

BEGIN 

READ-LEX ( ) 5 

sexpressi0n1 ( ) 5 
end; 
end; 

[OTHERWISE] s 

ERROR( 'Missing expression ' ) 5 

tes; 
end; 

An important aspect of this routine is that it recursively calls itself. 

Consider what might happen if SEXPRESSION1 has recursed several levels 
when an error is detected. This would happen, for example, for the following 
invalid input for an expression: 

(+Y+((Z(+0)) 

The left parenthesis marked by A is the point of error — a left parenthesis 
where there should be a right parenthesis. At this point SEXPRESSION1 has 
called itself three times. The problem is how to proceed after the error in a 
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reasonable way. One simple strategy is to stop expression parsing, discard any 
subsequent lexemes that could be part of an expression, and then return to 
the routine that called for expression parsing in the first place. 

A means to do this using condition handling (and the point of this whole 
example) is shown in the following pair of routines. The first routine, SEX- 
PRESSION, is the establisher routine. The only purpose of SEXPRESSION 

is to establish the second routine, SEXP ERROR, as a handler and then call 

SEXPRESSION1 to do the actual expression parsing. The routines are coded 
as follows: 

ROUTINE SEXPRESSION; NOUALUE = 
BEGIN 

ENABLE SEXP„ERRORS 
SEXPRES5I0N1 ( ) 5 
END 5 

ROUTINE SEXP._ERROR(SIG » MECH » ENAB) = 
BEGIN 
MAP 

SIG: REF VECTOR! 
BIND 

COND = SIGCi]: COND I T I 0N_VALUE 5 

! Resisfn al all but E X P _ E R R R t ignore unwi n d 

IF NOT STS$MATCH( .COND , EXP.„ERR0R) 
THEN RETURN 0! 

! Skip all lexemes that can be part of an expression* 

! Stop on any other lexeme. 

WHILE 

(SELECTONE .LEXTYPE OF 

SET 

[LEX_LPAREN » LEX-RPAREN » LEX_NAME » LEX-PLUS]: 1? 

[OTHERWISE]: 05 

TES) 
DO 

READ._LEX( ) 5 
SETUNWIND( ) ! 
RETURN 
END 5 

The coding for SEXP ERROR follows the template for condition handlers 

given in Section 17.4.2, but is simplified because not all of the parameters are 
used. The coding also assumes the declarations given in 17.6.1 for accessing 
condition values. 

If SEXPRESSION1 calls SIGNAL, then CHF skips over all of the calls to 
SEXPRESSION1 since no handler is established, and calls SEXP_ERROR. 

SEXP ERROR first tests whether the condition value is the one for an 

expression error. If not, then resignaling is requested. The same coding also 
causes an unwind signal to be ignored. It is valid in this case to not assign a 
return value for the establisher routine in the mechanism vector during 
unwinding because the establisher routine, SEXPRESSION, does not return 
a value. If the condition value does indicate an expression error then the 
WHILE loop causes lexemes that could be part of the erroneous expression to 
be read and ignored. (Recall that calling READ LEX changes the contents 
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of LEXTYPE. Because this change results from execution of a handler rou- 
tine, LEXTYPE must be declared with the VOLATILE attribute.) Finally, 
SETUNWIND is called to cause all of the calls to SEXPRESSION1 and the 
call to SEXPRESSION to be terminated. 

17.6.3 Performance Measurement 

In some cases condition handling is convenient for conducting certain kinds of 
performance measurement. This is particularly true when the analysis to be 
performed involves the dynamic calling relationship between routines. 

For example, suppose the desired information is the relative number of times 
that a certain routine, say R, is called directly or indirectly by each of two 
other routines, say Cl and C2. This can be accomplished by the following: 

1. Modify routine R to call SIGNAL at some appropriate point in its 
execution. 

2. Modify routines Cl and C2 to establish handlers, say C1H and C2H. 

3. Code C1H and C2H to increment counters each time a signal is received 
from R and then request continuation. 

4. Execute the modified program to collect the frequency data and analyze 
the results. 

It may also be prudent to modify the main routine to have a handler for the 
signal from R as well. This handler will be called if R signals when Cl or C2 
are not in the stack of executing routine calls. 

Observe that with this arrangement if Cl calls C2 calls R then the handler for 
C2 will be the one called. 

It is, of course, possible to get the same frequency data by modifying the 
routines to set and test various counters and flags directly. But, in cases such 
as this one, condition handling may well be simpler and more convenient. 

17.6.4 Target Operating Systems and Condition Handling 

Target operating system support and use of condition handling is discussed 
briefly in the following sections. 

17.6.4.1 PDP-11 Operating Systems — In BLISS-16, PDP-11 operating sys- 
tems generally do not support condition handling as described in this manual 
nor do they use condition handling in their internal operation. Condition 
handling for BLISS-16 is supported by software (the "CHF") in the 
BLISS-16 runtime library. 

17.6.4.2 The VAX/VMS Operating System — In BLISS-32, condition handling 
is directly supported by the condition handling facilities of the VAX/VMS 
operating system. The VAX/VMS system uses condition handling in several 
ways to achieve modular software components that can be flexibly used. 
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Condition handling plays a central role in reporting error messages. All error 
conditions are signaled using condition values and additional parameters that 
encode the error message to be reported. When the VAX/VMS command 
language processor starts up a user's program, it establishes its own handler, 
termed the catch-all handler, in a stack frame prior to the stack frame for the 
main routine. Consequently, the catch-all handler will be called for any sig- 
nals that are not handled by the user's program. 

The catch-all handler is programmed to interpret the system's condition val- 
ues and output the appropriate error messages. In addition, the catch-all 
handler interprets the severity field as follows: If severe error is given, then 
the user program image is terminated; otherwise, the handler returns to CHF 
requesting continuation. Observe that if the signal was generated using SIG- 
NAL STOP, the severity will necessarily be severe error (see Sections 17.3.2 

and 17.4.3.2). 

This design provides considerable flexibility in adapting system software to 
various applications. On the one hand, a program that does not establish any 
handlers will get standard system error messages. On the other hand, a pro- 
gram can establish a handler that will modify some or all of the system 
condition values in order to provide messages that are more appropriate to 
particular groups of users. For example, in a data base inquiry application 
used by non-technical personnel, a condition value for a subtle disk allocation 
problem can be replaced by a condition value for a message such as "System 
malfunction. Please call computer operations for assistance." 

The VAX/VMS system provides exception vectors that provide a means to 
establish handlers that will be called before CHF begins searching the stack of 
routine calls for handlers and for certain cases where CHF encounters an 
invalid stack frame. The DEBUG module uses an exception vector to estab- 
lish a handler to intercept signals for analysis and program testing purposes. 

In certain special cases, the FORTRAN Run Time Library establishes a han- 
dler between the command processor catch-all handler and the user's main 
program to deal with various conditions specific to itself. 

When reading the VAX/VMS manuals concerning condition handling, ob- 
serve that the VAX/VMS software calls a handler with two parameters, the 
signal vector and mechanism vector, rather than three parameters as de- 
scribed in Section 17.4.2. The BLISS system itself provides the enable vector 
parameter in addition to the two provided directly by VAX/VMS. 

17.6.4.3 TOPS-10 and TOPS-20 Operating Systems — In BLISS-36, the 
TOPS-10 and TOPS-20 operating systems generally do not support condition 
handling as described in this manual nor do they use condition handling in 
their internal operation. Condition handling for BLISS-36 is supported by 
software (the "CHF") in the BLISS-36 runtime library. 
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Chapter 18 
Special Features 



The preceding chapters describe declarations for the names of data, struc- 
tures, routines, conditions, bound values, lexical functions, and macros. This 
chapter describes the remaining declarations of BLISS. These declarations 
make use of the general declaration mechanism of BLISS for some rather 
specialized purposes. They are: 

• The psect-declaration, which specifies the required properties of the pro- 
gram sections used in a program. 

• The switch-declaration, which permits the specification of compiler 
switches for any block of a program. 

• The builtin-declaration, which makes available certain names that are 
predefined but not predeclared. 

• The label-declaration, which is used in connection with the exit-expres- 
sions. 



• 



The undeclare-declaration, which cancels the effect of any other kind of 
declaration for a given name. 



18.1 Psect-Declarations 



The psect-declaration allows the programmer to inform the linker about the 
storage characteristics required for different sections of his program, and al- 
lows him to group various kinds of object code in an efficient manner. 

He can, for example, request that a given program section be write-protected 
(which it normally might not be), or request that a given section be allocated 
in the same memory space as a section by the same name from another 
module. Also on some target systems he can request that a given section be 
shareable by several different processes. 
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Most of the program-section characteristics, called psect-attributes, are very 
target-system specific. Therefore the psect-declaration is in general not trans- 
portable, although it can be used transportably in a limited fashion. 

A psect-declaration can be used to allow a BLISS program to share data with 
a program written in another language. In the VAX-11 environment, for ex- 
ample, another use of the psect-declaration allows a set of modules to share a 
workspace whose size is determine4 by the linker, based on the needs of the 
particular set of modules present. * 

A psect-declaration can also be used to provide a second level of control over 
program organization. The first level of control is specified by the division of a 
program into modules. A second level of control is sometimes necessary if the 
division into modules (and the default program sections, where supplied) does 
not by itself provide the best organization of storage for efficient execution or 
debugging. 

Examples of psect-declarations are given in the following block: 

OWN 



PSECT 


OWN = ALPHA(NOWRITE) 


OWN 




C : 


t 


D , 


> 


E ■ 


! 


PSECT 


OWN = BETA(EXECUTE) 5 


OWN F: 


: VECTORC 10] i 



The data segments for the OWN variables A and B are allocated in the 
default program section for the storage-class OWN. The data segments for C, 
D, and E are allocated in the program section ALPHA, which cannot be 
written into. The data segment for F is allocated in the program section 
BETA, which can be executed. 

BLISS is unusual if not unique among higher-level languages in providing the 
kind of storage-allocation control permitted by the psect-declaration. As 
stated above, however, its usage is for the most part nontransportable. 
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18.1.1 Syntax 



psect-declaration 



PSECT psect-item ,... ; 



psect-item 



storage-class = psect-name 

{( psect-attribute ,... ) ) 
nothing J 



storage-class 



OWN 

GLOBAL 

PLIT 

CODE 

NODEFAULT 



psect-name 



name 



psect-attribute 



WRITE I NOWRITE 
EXECUTE I NOEXECUTE 
OVERLAY I CONCATENATE 
bl6-psect-attribute 
b32-psect-attribute 
b36-psect-attribute 



<=16 Only 
<=32 Only 
<=36 Only 



16 Only=> 
bl6-psect-attribute 



LOCAL I GLOBAL 



32 Only=> 






/ READ 1 NOREAD \ 




1 SHARE 1 NOSHARE 1 




1 PIC 1 NOPIC ( 


b32-psect-attribute 


< LOCAL 1 GLOBAL > 




1 VECTOR 1 




I alignment-attribute 1 




\ addressing-mode-attribute / 



36 Only=> 
b36-psect-attribute 


( READ 1 NOREAD ) 
( ORIGIN(address-expression) ) 


address-expression 


compile-time-constant-expression 
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The alignment-attribute is described in Section 9.5 and the addressing-mode- 
attribute is described in Section 9.13. 



18.1.2 Restrictions 

In the definition of the psect-attribute, most attributes are given in mutually 
exclusive pairs: WRITE and NOWRITE, OVERLAY and CONCATENATE, 
and so on. Both members of such a pair may not be used in declaring a single 
psect-name. The alignment-attribute, the addressing-mode-attribute, and the 
ORIGIN attribute are not members of such pairs. 

All declarations of a given psect-name in a program must provide the same set 
of psect-attributes for the name. This restriction is applied after any missing 
attributes have been supplied by the default rules. 

BLISS-32 ONLY 

The value of the boundary expression in an alignment-attribute for a pro- 
gram section must be in the range through 9. 

The value of that boundary expression must not be exceeded by the value of 
the boundary expression in an alignment-attribute for any data segment 
that is allocated in the program section. 

BLISS-36 ONLY 

A psect-name must be unique among all other psect-names within its first 
six characters, due to linker restrictions. 

If a declaration of a psect-name other than $LOW$ or $HIGH$ appears in a 
module, the first (or only) such declaration must appear before any data- or 
routine-declarations (other than the external or forward forms), and before 
any expression containing a plit. That is, it must appear before the first 
declaration that causes storage to be allocated or object code to be gener- 
ated. 

The value of the address-expression in the ORIGIN attribute must be in the 
range to (2**18)-1 inclusive. 

18.1.3 Defaults 

BLISS-16 ONLY 

The following psect-declaration is assumed to appear in an imaginary block 
that surrounds each module: 

PSECT 

OWN = $OWN$ (WRITE fNOEXECUTE (CONCATENATE tLOCAL) » 

GLOBAL = $GLOBAL$ ( WR I TE tNOEXECUTE (CONCATENATE (LOCAL ) » 

PLIT = $PLIT$ (JMOWRITE (NOEXECUTE (CONCATENATE (LOCAL) » 

CODE = .$CODE$ (NOWRITE (EXECUTE (CONCATENATE (LOCAL) 5 

This declaration provides a default program section name for each of the 
four storage-classes. The psect-attributes used are exactly the default 
psect-attributes that are given in the following paragraph. 
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If a psect-item contains- a parenthesized list of psect-attributes, then any 
missing attributes are filled in by default. The defaults are: 



Attribute 

WRITE I NOWRITE 
EXECUTE I NOEXECUTE 
OVERLAY I CONCATENATE 
LOCAL I GLOBAL 

BLISS-32 ONLY 



Default 

WRITE 
NOEXECUTE 
CONCATENATE 
LOCAL 



Exception 



EXECUTE for CODE 



The following psect-declaration is assumed to appear in an imaginary block 
that surrounds each module: 



PSECT 




OWN 


= *OWN$ 


GLOBAL ' 


= $GLOBAL$ 


PLIT 


= $PLIT$ 


CODE : 


= *C0DE$ 



(READ »WRITE , NOEXECUTE »NOSHARE » 
NOPIC t CONCATENATE » LOCAL »ALIGN(2) » 
ADDRESSING„MODE(WORD_RELATK>E) ) * 
(READ tWRITE »NOEXECUTE »N0SHARE * 
NOPIC t CONCATENATE » LOCAL »ALIGN(2) » 
ADDRESSING_MODE(WORD_.RELATK'E) ) » 
(READ »NOWRITE >NOEXECUTE tNOSHARE t 
NOPIC » CONCATENATE t LOCAL »ALIGN(2) t 
ADDRESSING_MODE(WORD_RELATIVE) ) t 
(READ »NOWRITE ^EXECUTE »NOSHARE t 
NOPIC » CONCATENATE , LOCAL >ALIGN(2) » 
ADDRESSING_MODE(NORD_RELATIUE) ) i 

This declaration provides a default program section name for each of the 
four storage-classes. The psect-attributes used are exactly the default 
psect-attributes that are given in the following paragraph. 

If a psect-item contains a parenthesized list of psect-attributes, then any 
missing attributes are filled in by default. The defaults are: 



Attribute 

READ I NOREAD 

WRITE I NOWRITE 

EXECUTE I NOEXECUTE 

SHARE I NOSHARE 

PIC I NOPIC 

OVERLAY I CONCATENATE 

LOCAL I GLOBAL 

alignment-attribute 

addressing-mode-attribute 



Default Exception 

READ 

WRITE NOWRITE for PLIT or CODE 

NOEXECUTE EXECUTE for CODE 

NOSHARE 

NOPIC 

CONCATENATE 

LOCAL 

ALIGN(2) 

ADDRESSING_MODE(WORD_ 

RELATIVE) 



BLISS-36 ONLY 

The following psect-declaration is assumed to appear in an imaginary block 
that surrounds each module: 



PSECT 

OWN 



GLOBAL 

PLIT 

CODE 



$LOW* (READ ♦ WRITE » EXECUTE » CONCATENATE t 

ORIGIN(O) ) t 
$LOW$ (READ »WRITE ^EXECUTE ^CONCATENATE , 

ORIGIN(O) ) , 
$HIGH$ (READ >N0WRITE, EXECUTE, CONCATENATE, 

ORIGIN (7,0 '400000' ) ) » 
$HIGH$ (READ , NOWRITE , EXECUTE , CONCATENATE , 

ORIGIN (7.0 '400000' ) ) i 
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This declaration provides a default program-section name for each of the 
four storage-classes. The psect-attributes used are exactly the default 
psect-attributes that are given in the following paragraph. 

If a psect-item contains a parenthesized list of psect-attributes, then any 
missing attributes are filled in by default. The defaults are: 

Attribute Default Exception 

READ I NOREAD + READ 

WRITE I NOWRITE WRITE NOWRITE for PUT or CODE 

EXECUTE I NOEXECUTE EXECUTE 

OVERLAY I CONCATENATE CONCATENATE 

There is no default for the ORIGIN attribute: if it is not specified, then the 
corresponding program-section origin must be specified at link time (/SET 
switch of the LINK command). Further, there is no default for the address- 
expression of this attribute. 

If a psect-item does not contain a parenthesized list of psect-attributes and if 
a previous declaration of the psect-name is given in the module, then the 
psect-attributes are taken from the first declaration of the same psect-name. 

18.1.4 Semantics 

NODEFAULT is a special storage-class which allows the declaration of a 
psect without overriding current defaults for OWN, GLOBAL, PLIT, or 
CODE data; thus, the current defaults need not be either known or restored. 
For example, the following declarations allow a longword to be shared be- 
tween BLISS-32 and VAX-11 PL/1: 

PSECT 

NODEFAULT = PL 1-DATA < ABSOLUTE »0VERLAY >READ »WRI TE ) 5 

OWN 

PL1_DATA : PSECT ( PL1 -DATA ) 5 

With the last declaration, PL/1 will expect global and external symbols to be 
declared in an overlayed psect of the same name; moreover, note that it has 
not been necessary to again declare the defaults. In the following sections, the 
semantics of the psect-declaration are given in four parts. First, the storage- 
classes are described. Next, the program section attributes are given. Then, 
psect-names and their scope are discussed. Finally, the interpretation of a 
psect-declaration is given. 

18.1.4.1 Storage-Classes — The storage-class in a psect-item determines the 
kind of data that is allocated in the corresponding program section. The 
following list indicates the declarations or primaries that are associated with 
each storage-class. 

Declaration or Primary Storage-Class 

OWN declarations OWN 

GLOBAL declarations GLOBAL 

plits PLIT 

ROUTINE and GLOBAL ROUTINE declarations CODE 



18-6 Special Features 



In other words, any data segments allocated by the compiler in processing 
OWN declarations are allocated in program sections declared for the storage- 
class OWN; any data segments allocated in processing GLOBAL data decla- 
rations are allocated in program sections for the storage-class GLOBAL; and 
so on. 

1 8.1 .4.2 Psect-Attributes — The attributes of a program section provide infor- 
mation to the linker about the way the program section should be allocated in 
storage. After the default psect-attributes have been filled in, a psect-name 
has four attributes in BLISS-16, nine attributes in BLISS-32, or five attri- 
butes in BLISS-36 (assuming program-section generation), one from each of 
the following lines: 

READ NOREAD <=32/36 Only 

WRITE NOWRITE 

EXECUTE NOEXECUTE 

OVERLAY CONCATENATE 

SHARE NOSHARE <=32 Only 

PIC NOPIC <=32 Only 

LOCAL GLOBAL <=16/32 Only 

ALIGN(boundary) <=32 Only 

ADDRESSING_MODE(mode) <=32 Only 

ORIGIN(address) <=36 Only 

(The ORIGIN address-value has nojlefault.) In addition to the above, the 
VECTOR psect-attribute may be specified in BLISS-32. 

The READ, WRITE, and EXECUTE attributes determine which kinds of 
access to the program section are permitted. Based on these attributes, the 
linker establishes the hardware memory-management access control needed 
for the storage of the program section, assuming that a target system's 
hardware/software environment does in fact provide the required facilities. 
(Some attributes have no effective meaning for a given target system, but are 
allowed in the corresponding dialect because of transportability considera- 
tions.) 

The OVERLAY attribute causes program sections that have the same name 
but come from different modules to be allocated in the same storage (like 
FORTRAN COMMON blocks, for example). The CONCATENATE attribute 
causes program sections with the same name from different modules to be 
allocated contiguously, each in its own storage. 

BLISS-16/32 ONLY 

The LOCAL and GLOBAL attributes provide indicators for the target- 
system linker, which uses them in the allocation and management of physi- 
cal memory for a program. In BLISS-16, these indicators direct the con- 
struction of program overlays. In BLISS-32, these indicators direct the 
grouping of pages within a program image so as to optimize performance. 

BLISS-32 ONLY 

The SHARE attribute specifies that the program section can be accessed by 
more than one process. 
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The PIC (Position Independent Code) attribute indicates that the program 
section can be relocated without affecting its validity. 

The alignment- attribute causes the storage for the program section to begin 
with a byte whose address ends with at least n zero bits, where n is the 
value of the boundary expression in the alignment-attribute. This attribute 
also causes the storage for the program section to be extended, if necessary, 
with unused bytes until its last byte is just before a byte whose address ends 
with at least n zero bits. Thus, for-example, an ALIGN(l) attribute causes a 
program section to begin and end at word boundaries, an ALIGN(2) at 
longword boundaries, and so on. The alignment-attribute is further de- 
scribed in Section 9.5. 

The addressing-mode-attribute determines the addressing mode for each 
data segment allocated in the program section. The significance of the 
addressing mode is given in Section 9.13. 

The VECTOR psect-attribute causes generation of an indication to the 
linker that the program section contains 'entry-point vector' information for 
a VAX/VMS privileged shared image, used in the construction of shared 
run-time libraries. (Analogous to the VEC attribute in VAX-11 MACRO.) 

BLISS-36 ONLY 

The ORIGIN attribute specifies the machine address at which a program 
section is to start. For example, ORIGIN(%0 '400000 ') will cause the corre- 
sponding program section to start at the standard high-segment beginning 
address, 400000 octal. Note that the use of this attribute can result in 
unallocated storage left between two program sections, or in overlapping 
program sections. Proper use of this attribute must be guided by familiarity 
with the linker for the target system in question. 

A complete understanding of the program-section attributes requires knowl- 
edge of the way storage is or can be laid out by the linker. Information on the 
allocation of storage can be found in the appropriate linker (or task-builder) 
reference manual for the target system. See also the appropriate BLISS User's 
Guide for additional information. 

18.1.4.3 Psect-Names — A psect-name is interpreted by the linker and is, 
necessarily, global to a module. The first declaration of a given psect-name 
within a module serves two purposes. First, it establishes the name and de- 
fines the attributes for the program section associated with that name for the 
scope of the module. Second, the first declaration of a given name establishes 
the program section associated with that name as the current program section 
for the storage class in the scope in which it is declared. Thus, unless a 
NODEFAULT storage class is used to prevent an override of the default 
attributes (see Section 18.1.4), subsequent declarations of the psect-name will 
serve only the second purpose, which is: to establish the current program 
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section for a storage-class. All declarations of a particular psect-name within a 
module must be equivalent. Psect- declarations are equivalent if one of the 
following applies: 

• The declarations are identical. 



• 



• 



The declarations have the same set of attributes after the missing attrib- 
utes have been filled in by default. 

The second of the two declarations has no parenthesized list of attributes. 
(In this case, the attributes from the first declaration apply to the second 
declaration.) 

18.1.4.4 Interpretation — Every use of the same psect-name in a program 
refers to the same program section. A psect-declaration not only states (or 
restates) the psect-attributes for a given program section, but also selects that 
program section for use within the scope of the declaration for a given storage - 
class. 

18.1.5 Discussion 

The simplest way to ensure that all declarations of a psect-name in a given 
module are equivalent is to use the simple form of a psect-declaration, in 
which no parenthesized list of attributes is given, for all psect-declarations 
except the first one. Consider the following program segment: 

BEGIN 
ROUTINE S= 

BEGIN 

PSECT OWN = ALPHA (NOWRITE)i 

OWN SI 5 

4 ♦ ♦ 

END 
OWN At B5 
PSECT OWN = beta; 
own c; 

♦ ♦ ♦ 

PSECT OWN = ALPHAS 
OWN D5 

♦ ♦ ♦ 
END 

The first declaration of the psect-name ALPHA defines the name and estab- 
lishes its attributes; in BLISS-32, for example: 

READ, NOWRITEf NOEXECUTE > NOSHARE » NOPIC, CONCATENATE , LOCAL , 
ALIGN(2) » ADDRESSING„MODE< WORD-RELATIVE) 

The NOWRITE attribute is given explicitly in the psect-declaration and the 
other attributes are determined by default. The subsequent declaration of the 
psect-name ALPHA does not have a parenthesized list of attributes; there- 
fore, the list associated with the previous declaration is assumed. Note that 
giving these declarations in the opposite order results in an error. 
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Data and routines from different storage-classes can be allocated in the same 
program section by means of the appropriate psect-declarations. For example, 
suppose that all plits for a given module must be allocated in the same 
program section that is used for the object code for routines. Then the follow- 
ing declaration can be written in the outer block of the module: 

PSECT 

PLIT = $CODE$? 

This declaration overrides the default psect-declaration for the PLIT storage- 
class, which allocates plits in the program section named $PLIT$. 

Consider, again, the module described in the previous paragraph. Suppose the 
following declaration appears in an inner block of that module: 

PSECT 

PLIT = $PLIT$5 

Within the block in which this declaration appear, plits are allocated in the 
default program section for plits, just as if the declaration mentioned in the 
preceding paragraph was not present. 



18.2 Switches-Declarations 



A switches-declaration allows a programmer to give the compiler additional 
information about the desired interpretation of a block. In this way, each 
block can be given individual treatment by the compiler. 

For example, a block that is still in the debugging process can have a 
switches-declaration that causes the compiler to provide listings, error mes- 
sages and macro expansion traces for that block. Or, a block in an inner loop 
can have a switches-declaration that causes the compiler to perform special 
optimizations. 

An example of a switches-declaration is given in the following block: 



BEGIN 

♦ ♦ ♦ 



BEGIN 

SWITCHES N0ERRS5 

♦ ♦ ♦ 

END ! 



♦ ♦ ♦ 

END 



The inner block has a switches-declaration that specifies that no warning or 
error messages are to be displayed for that block. 

Some switch-items, such as ADDRESSING MODE, simply set attribute 

defaults for the remainder of the block, and thus have only an indirect 
effect — that is, through other declarations later in the block that take those 
defaults. 

In general, the actions or interpretations requested by a switches-declaration 
only take effect subsequent to the occurrence of the declaration (from the 
viewpoint of code generation). Therefore, in the normal case where the effect 
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is desired throughout the block in question, the correct positioning of the 
switches-declaration is at the very beginning of the block (i.e., prior to any 
code-producing declaration). 



18.2.1 Syntax 



switches-declaration 



SWITCHES switch-item 



switch-item 



(on-off-switch-item ) 
special-switch-item ) 



on-off-switch-item 



ERRS I NOERRS 
OPTIMIZE I NOOPTIMIZE 
SAFE I NOSAFE 

UNAMES I NOUNAMES 
ZIP I NOZIP 



special-switch-item 



ADDRESSING_MODE 

( mode-spec ,... ) 
LANGUAGE ( language-list ) 
LINKAGE ( linkage-name ) 
LIST (list-option ,...) 
STRUCTURE 

( { structure-attribute } ) 
{ nothing } 



<=32 Only 



language-list 



{ 



COMMON 

language-name ,. 
nothing 



} 



language-name 



BLISS16 I BLISS32 I BLISS36 



linkage-name 



name 



list-option 



SOURCE I NOSOURCE 
REQUIRE I NOREQUIRE 
EXPAND I NOEXPAND 
TRACE I NOTRACE 
LIBRARY I NOLIBRARY 
OBJECT I NOOBJECT 
ASSEMBLY I NOASSEMBLY 
SYMBOLIC I NOSYMBOLIC 
BINARY I NOBINARY 
COMMENTARY I NOCOMMENTARY 
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32 Only => 
mode-spec 


i EXTERNAL = mode ) 
\ NONEXTERNAL = mode J 


32 Only => 
mode 


/ GENERAL \ 
1 ABSOLUTE 1 
1 LONG—RELATIVE ( 
V WORD_RELATIVE / 



The structure -attribute is defined in Section 11.4. 

18.2.2 Restrictions 

An ADDRESSING_MODE switch may have no more than one EXTERNAL 
mode-spec and no more than one NONEXTERNAL mode-spec (BLISS-32 
only). 

The linkage-name in a LINKAGE switch must either be explicitly declared as 
a linkage-name in a containing block or must be a predeclared linkage-name. 

The structure-name in the structure-attribute of a STRUCTURE switch must 
either be explicitly declared as a structure-name in a containing block or must 
be a predefined structure-name. 

18.2.3 Defaults 

If a switch-item is not specified, the setting established by the compilation 
command specification, by the module-head or by a switches-declaration in 
an outer block is assumed. 
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If a null language-list appears in a LANGUAGE switch (i.e, 
LANGUAGE () ), the single language-name corresponding to the compiler in 
use is assumed. This implies that no transportability checking is to be per- 
formed within the scope of the containing block. 

If the keyword COMMON appears in the language-list of the LANGUAGE 
switch, it is equivalent to the explicit specification of all three language- 
names. 



18.2.4 Semantics 

The switch-items specify actions to be taken by the compiler in processing a 
block. 

In addition to the following description, additional discussion of the compiler 
actions for these switches can be found in the BLISS User's Guide for the 
appropriate compiler. 

18.2.4.1 On-Off-Switch-ltems — Each on-off-switch-item has a negation, 
which consists of the switch-item prefixed by the characters "NO". The nega- 
tion of a switch-item indicates that the associated action should not be taken. 
The action associated with each switch-item is given in the following list: 

Switch-Item Action 

ERRS Print warnings and error messages from the compiler on 

the terminal. 

OPTIMIZE Perform optimization across mark points. 

SAFE Ignore computed addresses in doing optimization. 

UNAMES Generate unique names for OWN variables, non-global 

ROUTINE names, and LABELs when producing a listing 
that is to be assembled. 

ZIP Optimize time at the expense of space. 
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18.2.4.2 Special-Switch-ltems — The special-switch-items provide additional 
information about the block being compiled. The action associated with each 
special-switch-item is given in the following list: 



Switch-Item 

ADDRESSING_MODE 
( mode-spec, ... ) 



LANGUAGE 

( language-list ) 



LINKAGE 

( linkage-name ) 



LIST 
( list-option, 



STRUCTURE 

( structure-attribute ) 



Action 

<= BLISS-32 Only 

Establish the given addressing modes as the ad- 
dressing-mode defaults for subsequent declara- 
tions in the current block. An EXTERNAL 
mode-spec supplies the default for EXTERNAL 
and EXTERNAL ROUTINE declarations. A 
NONEXTERNAL mode-spec supplies the de- 
fault for FORWARD, FORWARD ROUTINE, 
and PSECT declarations. (This default is inef- 
fective unless a program section is declared 
within the block.) The addressing-mode attrib- 
ute is described in Section 9.11. 

Establish the given list of language-names for 
the remainder of the current block. Perform 
transport-ability checking, if applicable, for the 
combination of dialects specified or implied in 
the list. See Section 18.2.5 and Appendix C for 
further information. 

Establish the given linkage-name as the linkage- 
name default for the remainder of the current 
block. This linkage-name is used as the linkage- 
attribute of any subsequent routine declaration 
in the current block that does not specify a link- 
age-attribute. 

Establish the given list-options for the output 
listing of the remainder of the current block. The 
list-options are described in the following sub- 
section. 

Establish the given structure-attribute as the de- 
fault structure-attribute to be used in subse- 
quent default-structure-references within the 
current block (see Sections 11.4 and 11.8). If the 
given structure-attribute is null, then all subse- 
quent default-structure-references in the block 
are invalid. 



18.2.4.3 List-Options — The output listing produced as a result of a BLISS 
compilation can contain several separate parts, namely: 

source listing 

macro expansions and traces 
library usage traces 
object code listing 
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The LIST switch-item controls the parts of the output listing to be produced 
according to the settings specified by the list-options. The first two list-op- 
tions, SOURCE and REQUIRE, operate on a special counter, the source 
listing counter. The counter is initially set to 1, and source text is listed when, 
and only when, the value of the counter is greater than zero. Thus the 
SOURCE and REQUIRE list-options control the listing of the source text 
from files specified in the compilation command and by REQUIRE declara- 
tions. 

The action associated with each list-option is given in the following list. 



List-Option 

SOURCE 

REQUIRE 



EXPAND 
TRACE 

LIBRARY 
OBJECT 
ASSEMBLY 
SYMBOLIC 



BINARY 
COMMENTARY 



Action 

Increments the source listing counter. NOSOURCE 
decrements the source listing counter. 

Causes the source listing counter to be left unchanged 
when a file specified by a REQUIRE declaration is 
opened or closed. NOREQUIRE causes the source list- 
ing counter to be decremented when a file specified by 
a REQUIRE declaration is opened, and incremented 
when the file is closed. 

List the lexeme stream that is the result of each macro 
expansion. 

Trace the expansion of macros, printing each lexeme 
stream produced during the expansion and the final 
lexeme stream produced as as result of the expansion. 

Trace the usage of names whose declarations are ob- 
tained from library binary files. 

List the object code. The format of the listing is deter- 
mined by the settings of the following four switches. 

List the object code instructions in a form suitable for 
assembly. 

List the object code instructions in a form suitable for 
interpretation by the programmer. This format uses 
source program symbols wherever possible in the ob- 
ject code instructions. 

List the binary text of the object code. 

List commentary produced by the compiler concerning 
the object code generated. At present, commentary is 
limited to a line-number cross reference. 



18.2.5 Discussion 

The LANGUAGE switch is an aid in the development of transportable pro- 
grams. As a module-switch, it declares the programmer's intention to compile 
the module under several different compilers, for use on the corresponding 
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target systems. It requests that the compiler analyze the module from the 
standpoint of transportability. For example, with two compiler names speci- 
fied in the LANGUAGE switch, both compilers will check for and report the 
occurrence of certain machine-sensitive language features that may pose 
problems when the module is processed by the other compiler. 

Used in a SWITCHES declaration, this switch essentially allows the program- 
mer to "turn off transportability checking within the block immediately 
containing the declaration. The need for this capability arises, for example, 
where a given block is not coded transportably, e.g., is inherently machine- or 
system-dependent, and must be modified for each target system. 

The specific language constructs that are checked for a given set of target 
systems are described in Appendix C. Briefly, these constructs fall into the 
following categories: 

• All syntactic features that are not common to the target set. For example, 
if all three target systems are specified, then the occurrence of any dia- 
lect-specific feature is reported. 

• Most syntactic features that, although common to the target set, are 
likely in certain forms to cause transportability problems. For example, 
string-literals used as primary expressions. 

• Certain dialect-sensitive elements that may occur in otherwise valid con- 
structs; for example, field-selector values that are compile-time-constant- 
expressions are checked at compile time for conformance to the restric- 
tions imposed by the most restrictive target system. 

In general, the checks performed in response to the LANGUAGE switch alert 
the user to language features that most often require special attention when 
transporting programs. Such checking cannot, however, identify or resolve all 
of the problems that may be encountered. In particular, the functional equiv- 
alence of a program in several different environments cannot be assured (at 
compile time) in all cases, even though the program compiles sucessfully in 
each environment. 

Each BLISS User's Guide contains a section on "Transportability Guide- 
lines". A study of this section and frequent, parallel compilations of the mod- 
ule to be transported are strongly recommended. 



18.3 Builtin-Declarations 



Certain names are predefined in BLISS. Some of the predefined names are 
predeclared, so that they can be used without being declared explicitly; an 
example is the name ABS, which is the name of the absolute-value function. 
Other predefined names are not predeclared, but must, instead, be declared 
BUILTIN before they can be used. 

The classification of a given predefined name as predeclared or builtin is part 
of the BLISS language definition; it is given in Appendix A. Names that are 
frequently used and that apply to all dialects of BLISS are predeclared. 
Names that are predefined only in certain dialects of BLISS are builtin. In 
particular, all names of machine-specific-functions are builtin; these are 
listed in Appendix D. 
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18.3.1 Syntax 



builtin-declaration 


BUILTIN builtin-name ,... ; 


builtin-name 


name 



18.3.2 Restrictions 

Each name in a builtin-declaration must be listed in Appendix A under the 
classification "builtin name". 

A builtin-declaration containing a predefined register-name (see Section 
10.7.4) or a predefined name of a linkage-function (see Section 13.6) must be 
contained in a routine-declaration. 



18.3.3 Semantics 

A builtin-declaration informs the compiler that the names listed are used as 
builtin-names in the current block. 

The full definition of each builtin-name is given elsewhere in the definition of 
BLISS. For example, in BLISS-16 the builtin-name PC is a register-name 
and is defined in Section 10.7.4. For another example, the builtin-name 
BICPSW is a VAX-11 machine-specific-function name and is defined in the 
BLISS-32 User's Guide. 



18.4 Label-Declarations 



The use of labels is very restricted in BLISS. Labels are used only to identify a 
block so that a LEAVE expression can be used to terminate the evaluation of 
the block. When a label is used, it must be declared by a label-declaration. 

18.4.1 Syntax 



label-declaration 


LABEL label-name ,... ; 


label-name 


name 



18.4.2 Semantics 

A label declaration informs the compiler that the names listed are used as 
labels in the current block. 

The use of labels is discussed in connection with exit-expressions in Section 
6.6. 
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18.5 Undeclare-Declarations 



An undeclare-declaration is used to limit the scope of a declaration. An unde- 
clare-declaration in an inner block prevents references to names declared in 
outer blocks. An undeclare-declaration may also be used in a library source 
file to prevent a name from being entered into the precompiled library binary 
file (see Section 16.6). 

An example of an undeclare-declaration is given in the following block: 

BEGIN 

OWN A ,B tC 5 

BEGIN 
UNDECLARE A»C5 



END 



END 



In the inner block, the name B designates the OWN variable declared in the 
outer block, but the names A and C have no meaning. 

18.5.1 Syntax 



undeclare-declaration 


UNDECLARE undeclared-name ,... ; 


undeclared-name 


name 



18.5.2 Semantics 

An undeclare-declaration informs the compiler that each undeclared-name in 
the list has no declared meaning for the scope of the current block. 

A name that is undeclared may be subsequently declared for some other use 
within the scope of the declaration. 

A name that is undeclared at the end of a library compilation is not entered in 
the library binary file produced by the compiler. 

18.5.3 Pragmatics 

In order to redeclare a macro-name it must be "quoted" using the lexical 
function %QUOTE (see Section 15.5.13). Effectively this inhibits expansion of 
the macro-name at the point of redeclaration. For example, to undeclare the 
name ZYX declared as a macro-name elsewhere in the same module, the 
following form of declaration is required: 

UNDECLARE '/.QUOTE ZYX 

This requirement applies to any other redeclaration of a macro-name as well. 
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Chapter 19 

Modules and Programs 



This chapter concludes the description of BLISS by describing modules and 
programs. No new functional capability is introduced here; instead, the way 
in which a program interfaces with the compiler in particular and the target 
system in general is described. 

This chapter has four sections. The first section describes modules in a gen- 
eral way. The second section completes the description of modules by defining 
the module-switches. The third section describes the predefined names, which 
provide one form of connection between programs and the system. The fourth 
section describes programs. 



19.1 Modules 



The module is the compilation unit of BLISS. Each module is complete for 
purposes of compilation. However, a module is usually incomplete for pur- 
poses of execution because it often depends on information supplied by the 
other modules with which it is linked to form a program. The use of GLOBAL 
and EXTERNAL declarations allows these points of communication to be 
identified so that their resolution can occur at link time. 

The division of a program into modules helps define the fundamental organi- 
zation of the program. Declarations that have some property in common can 
be grouped into a single module. For example, if two routine-declarations are 
always used together, then grouping them in a module ensures that they are 
allocated together. For another example, if some declarations are subject to 
change when a new version of the program is produced, then grouping them 
together in a module makes it possible to change the program by only recom- 
piling a single module. 



19-1 



An example of a module is: 



MODULE COMPOOL (IDENT = '000015') = 

BEGIN 

GLOBAL LITERAL 

BUFSIZ = 22G t 

PAGESI2 = 132» 

FACTOR = 33s SIGNEDO) 5 
GLOBAL BIND X = PL IT (0fl»2»3»4»5f6»7»8»9fl0fll»12) 

: VECTOR C 13] 5 
END 
ELUDOM 

This module contains the constant declarations that are used in other mod- 
ules of the program. 

Another example of a module is: 

MODULE STK (IDENT = '000001') = 

BEGIN 

ONN STK s VECTOR CI 000] 5 

OWN STKPTR; INITIAL(O) i 

EXTERNAL ROUTINE 

STKERR1 » 

STKERR2 5 
GLOBAL ROUTINE PUSH(X): NOOALUE = 

BEGIN 

if .stkptr geq 1000 then stkerr1(>5 
stkptr = .stkptr + 1 ? 
stk c. stkptr] = .x! 
end; 
global routine pop(x): nooalue = 

BEGIN 

IF .STKPTR LSS THEN STKERRZOi 

.X = .STKC .STKPTR] ? 

STKPTR = .STKPTR-1 ; 

END? 
END 
ELUDOM 

This module contains both data-declarations and routine-declarations. 



19.1.1 Syntax 



module 


MODULE module-head = 
module-body 
ELUDOM 


module-head 


module-name ( < module-switch ,... ) ) 
( nothing J 


module-name 


name 


module-body 


block 
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19.1.2 Restrictions 

A module-body can contain only declarations at its outermost level; that is, it 
must be a sequence of declarations within a BEGIN-END or parenthesis pair. 
Some of these declarations can be routine-declarations, and these define the 
actions that can be performed by the module. 

Some declarations must not be given at the outermost level of a module, 
namely, declarations of temporary data segments and linkage-functions. 
These are: local-declarations (Section 10.5), stacklocal-declarations (Section 
10.6), register-declarations (Section 10.7), and builtin-declarations (Section 
18.3) that give any of the predefined register names (Section 10.7.4) or any of 
the names of linkage-functions (Section 13.6). 

19.1.3 Semantics 

A module provides the compiler with three items: 

• The module-name, which is used in some contexts (by the compiler) to 
identify the object code for the module. 

• The module-switches, which select various options offered by the com- 
piler. 

• The module-body, which is translated by the compiler from BLISS into 
an object code file. 



19.2 Module-Switches 



The module-switches allow a programmer to control some aspects of the com- 
piler's treatment of the module. The programmer knows the module's stage of 
development and its intended use; he can, therefore, use switches to cause 
additional operations to be performed and to suppress other operations. Con- 
sider the development of a typical module from syntax checking through 
debugging into production. At the beginning, the module is: 

MODULE Ml (I DENT = '0001 ' , N0C0DE t LIST < TRACE > » 

LANGUAGE(BLISS16 »BLISS32) ) = 
BEGIN 

END 
ELUD0M 

In this example, the module-switches direct the compiler to perform only a 
syntax check (NOCODE) and to trace the expansion of macros 
(LIST(TRACE)). The LANGUAGE switch signifies the programmer's intent 
to compile the module with both the BLISS-16 and BLISS-32 compilers. It 
requests that the compiler currently in use check for and report the appear- 
ance of dialect-sensitive language features that might cause problems in 
transporting the module across the specified systems. Switches that are not 
given explicitly are determined by the default rules. For example, the switch 
ERRS is assumed by default and therefore the compiler prints warnings and 
error messages at the programmer's terminal. 
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Later, when the module is being debugged, the switches are changed and the 
module becomes: 



MODULE Ml ( IDENT 
BEGIN 



'0005' t DEBUG* NOOPTIMIZE) 



END 
ELUDOM 

In this version, the module-switches direct the compiler to prepare the symbol 
table and the linkages required for use by a debugging package (DEBUG) and 
to omit certain kinds of optimization by the compiler of the generated object 
code (NOOPTIMIZE). When the module is ready for production, the switches 
are changed again and the module becomes: 



MODULE Ml ( IDENT 
BEGIN 

« ♦ ♦ 

END 
ELUDOM 



'0203 ' ) 



In this version, all the switches except the identification switch are omitted 
since the default rules are oriented toward a production module. 

19.2.1 Syntax 



module-switch 


{ on-off-switch I special-switch } 


on-off-switch 


/ CODE I NOCODE \ 
1 DEBUG 1 NODEBUG 1 
1 ERRS 1 NOERRS 1 
/ OPTIMIZE 1 NOOPTIMIZE > 
1 SAFE i NOSAFE 1 
1 UNAMES 1 NOUNAMES 1 
V ZIP 1 NOZIP / 


special-switch 


/ common-switch \ 
1 bliss-16-switch 1 <= 16 Only 
1 bliss-32-switch I <= 32 Only 
V bliss-36-switch / <= 36 Only 
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common-switch 



IDENT = quoted-string 
LANGUAGE ( language-list 
LINKAGE ( linkage-name ) 
LIST ( list-option ,... ) 
STRUCTURE 
( { structure-attribute } ) 
{ nothing } 

MAIN = routine-name 
OPTLEVEL ={0111213 
VERSION - quoted-string 



language-list 



{ 



COMMON 

language-name ,. 
nothing 



} 



language -name 



BLISS16 I BLISS32 I BLISS36 



list-option 



SOURCE I NOSOURCE 
REQUIRE I NOREQUIRE 
EXPAND I NOEXPAND 
TRACE I NOTRACE 
LIBRARY I NOLIBRARY 
OBJECT I NOOBJECT 
ASSEMBLY I NOASSEMBLY 
SYMBOLIC I NOSYMBOLIC 
BINARY I NOBINARY 
COMMENTARY I NOCOMMENTARY 



linkage-name 
routine-name 



name 



16 Only => 
bliss-16-switch 


( ADDRESSING_MODE ( mode-16 ) ) 
( ENVIRONMENT ( environ-16-option ,... )J 


mode- 16 


{ ABSOLUTE 1 RELATIVE } 


environ- 16-option 


{ EIS 1 NOEIS 1 LSI11 1 Til 1 PIC 1 ODT } 
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32 Only => 
bliss-32-switch 


ADDRESSING—MODE ( mode-spec ,... ) 


mode-spec 


( EXTERNAL = mode-32 ) 
\ NONEXTERNAL = mode-32 J 


mode-32 


/ GENERAL \ 
1 ABSOLUTE 1 
| LONG—RELATIVE ( 
V WORD— RELATIVE / 



36 Only => 
bliss-36-switch 


ADDRESSING— MODE ( mode-36 ) 
ENTRY ( global-name ,... ) 
ENVIRONMENT ( environ-36-option ,... ) 
OTS = quoted-string 
OTS—LINKAGE = linkage-name 


mode-36 


{ INDIRECT 1 NOINDIRECT } 


environ-36-option 


/ cpu-option \ 
1 monitor-option 1 
I ots-option | 
v stack-option / 


cpu-option 


{ KA10 1 KI10 1 KL10 1 KS10 1 EXTENDED ) 


monitor-option 


{ TOPS10 1 TOPS20 } 


ots-option 


( BLISS10— OTS ) 
( BLISS36C— OTS J 


stack-option 


STACK = segment-name 


global-name \ 
linkage-name / 
segment-name / 


name 



The structure-attribute is defined in Section 11.4. 

19.2.2 Restrictions 

The MAIN switch must appear once and only once in a program. 

The routine-name specified in the MAIN switch must be declared in a 
ROUTINE or GLOBAL ROUTINE declaration in the same module. 
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The VERSION switch may appear only in a module that also contains the 
MAIN switch. 

The name specified in the structure-attribute of a STRUCTURE switch must 
be a predeclared structure-name. 

BLISS-36 ONLY 

Each name specified in the ENTRY switch must be declared GLOBAL, 
GLOBAL ROUTINE, GLOBAL BIND, GLOBAL BIND ROUTINE, or 
GLOBAL LITERAL in the same module. 

The ots-option of the ENVIRONMENT switch must not appear together 
with either the OTS switch or the OTS_LINKAGE switch. 

The stack-option of the ENVIRONMENT switch may appear only in a 
module that also contains the MAIN switch. 

The quoted-string given in the VERSION switch must conform to the 
TOPS-10/20 version-number format, which is: 

oooa(oooooo)-o 

where o represents an octal digit and a represents an alphabetic character. 
Leading zeros are not required. 

The linkage-name in the OTS LINKAGE switch must either be prede- 
clared or must appear in a linkage-declaration preceding the first routine- 
declaration in the module. The named linkage-definition must not specify 
register parameter-locations or global-registers. 

19.2.3 Defaults 

If a setting for an on-off-switch is not given, the default setting for that switch, 
which is given in the following list, is assumed: 

CODE Generate object code 

NODEBUG Do not build table and linkages for DEBUG package 

ERRS Print compiler diagnostic messages on terminal 

OPTIMIZE Optimize across mark points 

SAFE Ignore computed addresses in performing optimization 

NOUNAMES Do not generate unique names 

NOZIP Do not optimize time at the expense of space. 

If a setting for a special-switch is not given, the following defaults are 
assumed: 

ADDRESSING_MODE( RELATIVE ) <= BLISS-16 Only 

Use the relative addressing mode for all generated instructions. 

ADDRESSING_MODE( EXTERNAL = WORD_RELATIVE , 

NONEXTERNAL = WORD—RELATIVE) <= BLISS-32 Only 
Use the short/relative form of address encoding as the ultimate address- 
ing-mode default. 
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ADDRESSING_MODE( NOINDIRECT ) <= BLISS-36 Only 

Do not use the indirect addressing mode for any generated instructions. 

ENVIRONMENT^ EIS ) <= BLISS-16 Only 

Produce the object module using instructions from the Extended Instruc- 
tion Set (ASH, ASHC, DIV, MUL, SOB, SXT) wherever appropriate. 

LANGUAGE( %BLISS16(BLISS16) %BLISS32(BLISS32) 
%BLISS36(BLISS36) ) 

The module is intended for compilation only by the compiler currently in 
use, and no transportability checking is to be performed. (See Section 
16.2.4 for a description of the predeclared macros shown above.) 

LINKAGE(BLISS) <= BLISS-16/32 
LINKAGE(BLISS36C) <= BLISS-36 Only 

Use the predefined linkage BLISS in BLISS-16 and -32, or the prede- 
fined linkage BLISS36C in BLISS-36, for any routine that does not spec- 
ify a linkage-attribute. 

LIST( SOURCE, NOREQUIRE, NOEXPAND, NOTRACE, 

NOLIBRARY, OBJECT, NOASSEMBLY, SYMBOLIC, 
BINARY, COMMENTARY ) 

List the source text, but not the text contributed by files specified in 
require-declarations. Do not list macro expansions or traces. Do not list 
library usage traces. List the object code instructions using symbolic 
names, the binary text, and commentary produced by the compiler. 

STRUCTURE () 

That is, the default structure-attribute is empty, and default-structure- 
references are invalid (see Section 11.7). 

OPTLEVEL = 2 

Perform all optimizations that can be invoked without making any 
special assumptions about the program. 

The BLISS-36 ENVIRONMENT switch defaults, except for the ots-option 
and stack-option, are established when a given BLISS-36 compiler is gener- 
ated. See the BLISS-36 User's Guide for details. 

The default for the ots-option is BLISS36C OTS. This implies the standard 

BLISS36C Object Time System filename for a given target environment, and 
implies the standard BLISS36C linkage for generating OTS routine calls. 

If the stack-option is not specified in a module that contains the MAIN 
switch, a 2048-word stack is established by default. 

The defaults for the OTS and OTS LINKAGE switches are, respectively, 

the standard OTS filename and the standard OTS linkage established by the 
(explicit or default) ENVIRONMENT switch ots-option. More specifically, 
the OTS_LINKAGE default can be either BLISS36C or BLISS10, depending 
upon the ots-option setting. 
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If a null language-list appears in a LANGUAGE switch (i.e, 
LANGUAGE () ), the single language-name corresponding to the compiler in 
use is assumed. (This is equivalent to the default for the entire LANGUAGE 
switch, as described above.) 

19.2.4 Semantics 

The module-switches inform the compiler either to take an action or to sup- 
press an action. The actions associated with the special-switches and on-off- 
switches are described in the following sections. 

19.2.4.1 Special-Switches — The special-switches ADDRESSING—MODE 
(in BLISS-32), LANGUAGE, LINKAGE, LIST, and STRUCTURE can be 
used in a switches-declaration as well as in a module-head; those switches are 
described in Section 18.2. (See Appendix C also for further information on the 
LANGUAGE switch and transportability checking.) 

The special-switches that can be used only as module-switches are defined as 
follows: 

Special-Switch Action 

ADDRESSING_MODE ( mode-16 ) <= BLISS-16 Only 

Generate instructions using absolute or rel- 
ative addressing mode as indicated. 

ADDRESSING—MODE ( mode-36 ) <= BLISS-36 Only 

Generate instructions using indirect or 
noindirect addressing mode as indicated. 

ENTRY ( name ,... ) <= BLISS-36 Only 

Produce an object-module record that con- 
tains the specified global (i.e. entry) names, 
for use by the linker when forming a library 
of object modules. 

ENVIRONMENT ( environ-16-option ) <= BLISS-16 Only 

EIS: Generate object code employing in- 
structions from the PDP-11 Extended In- 
struction Set. 

NOEIS: Generate object code employing 
only the instructions available to all 
PDP-11 models. 

LSI11: Generate object code employing 
only the instructions available to the 
LSI-11 processor. 

Til: Generate object code employing only 
the instructions available to the Til proces- 
sor. 

PIC: Generate Position Independent Code. 

ODT: Facilitate debugging with ODT. 
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ENVIRONMENT ( environ-36-options ) <= BLISS-36 Only 

Cpu-option: Specifies the processor model 
of the target system for which code is to be 
generated. 

Monitor-option: Specifies the operating 
system of the target system for which code 
is to be generated. 

Ots-option: Specifies which of the standard 
object-time systems is to be used (at link- 
time) to satisfy outstanding external refer- 
ences, and implies the corresponding stand- 
ard linkage to be used for OTS calls (which 
may differ from the default linkage for non- 
OTS calls). 

Stack-option: Specifies the name of an 
OWN or GLOBAL data-segment declared 
in the same (main) module to be used as 
the control stack for the program, in place 
of a default compiler-generated segment. 



IDENT = 'xxx' 



MAIN = routine-name 



OPTLEVEL = level 



OTS = 'ots-file-spec' <= 



Include the quoted-string as an identifica- 
tion in the object module generated from 
the compilation of the module. (Currently 
effective in BLISS-16 and BLISS-32 only; 
see the appropriate BLISS user's guide for 
any applicable restrictions.) 

Save the routine-name. Program execution 
will begin with a routine-call on the routine 
designated by this routine-name. 

Use the value of level as a guide for the 
kind of optimizations performed, as follows: 

Level Meaning 

Minimum Optimization 

1 Low Optimization 

2 Normal Optimization 

3 Maximum Optimization 

The level value produces the most read- 
able object code. 

BLISS-36 Only 

Use the specified object-module library file 
when searching for object-time-system 
routines instead of the standard OTS file 
implied by the ots-option (see ENVIRON- 
MENT). 

Note that LINK-20 requires that the 
quoted file-spec conform to the TOPS-10 
style (i.e. DEV:[PPN]filnam ). 



19-10 Modules and Programs 



OTS_LINKAGE = linkage-name <= BLISS-36 Only 

Use the named linkage-definition when 
generating calls to the object-time-system 
identified in the OTS switch. 



VERSION = 'version-number' 



Include the quoted-string as an identifica- 
tion in the executable image of the program 
generated by linking the "main" module 
containing this switch. (Currently effective 
in BLISS-36 only.) 



BLISS-32 ONLY 



The quoted-string given with the IDENT special-switch is printed by the 
linker in the map it produces as a result of linking the modules of a pro- 
gram. This quoted-string usually contains an identifier that is used to 
determine which version of an object module is present in a program. 

BLISS-36 ONLY 

The quoted-string given with the VERSION special-switch is placed in the 
"version number" location of the executable image produced as a result of 
linking the modules of a program. (Note that the module containing the 
VERSION switch must also contain the MAIN switch.) This quoted-string 
must contain a conventional version number that is used to identify the 
version level of a program. 

19.2.4.2 On-Off-Switches — The on-off-switches ERRS, OPTIMIZE, SAFE, 
UN AMES, and ZIP can be used in a switches-declaration as well as in a 
module-head; those switches are described in Section 18.2. The on-off- 
switches that can be used only as module-switches are defined as follows: 

On-Off-Switch Action 

CODE Generate the object code for the module. 

DEBUG Build the symbol table and the linkages required for use 

of the debugging package. 

Each of these switches has a negation, formed by prefixing the switch name 
with NO. The negated switch means that the indicated action should not be 
taken. 
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Some names have a predefined, specific meaning that is part of the definition 
of BLISS. For example, ABS is the name of the absolute value function, and 
VECTOR is the name of a predefined vector structure. 

There are two kinds of predefined names: predeclared and builtin. The prede- 
clared names can be used without any declaration; indeed, a predeclared 
name must not be declared wherever it is used in its predefined sense. On the 
other hand, a builtin name must be declared BUILTIN wherever it is used in 
its predefined sense. 
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It is important to note that predefined names are not reserved. A predefined 
name can be declared for some user purpose (for example, as the name of a 
data segment or a macro or a routine). Within the scope of such a declaration, 
the predefined meaning of the name is lost; but if that meaning is not re- 
quired, no damage is done. 

The names that are predefined in the versions of BLISS that are described in 
this manual are listed in the following paragraphs. Additional predefined 
words will be added to BLISS as the language grows. 

Predeclared Standard-Function-Names — The following names are prede- 
clared as standard-function-names: 

SIGN, ABS 

MAX, MAXU, MAXA 

MIN, MINU, MINA 

%REF 

The description for each of these standard-function names is given in Section 
5.2. 

Builtin Register-Names — The predefined register-names must be declared 
BUILTIN wherever they are used as such. The register-names that are prede- 
fined for each dialect are described in Section 10.7.4. 

Predeclared Structure-Names — The following names are predeclared as 
names for predefined structures: 

BITVECTOR 
BLOCK 

BLOCKVECTOR 
VECTOR 

The structure-declaration for each of these structure-names is given in Sec- 
tion 11.9. 

Predeclared Linkage-Names — The following names are predeclared as link- 
age-names: 

BLISS <= 16/32 only 

FORTRAN <= 16/32 only 

FORTRAN_FUNC 

FORTRAN_SUB 

BLISS36C <= 36 only 

BLISS10 <= 36 only 

The description of these linkage-names is given in Section 13.5. 

Builtin Linkage-Functions — The following predefined names of linkage-func- 
tions must be declared BUILTIN wherever they are used as such: 

ACTUALCOUNT 

ACTUALPARAMETER 

ARGPTR 

NULLPARAMETER <= 16/32 only 

The description of these linkage-functions is given in Section 13.6. 
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Predeclared Condition- Handling -Functions — The following names are 
predeclared as names of condition-handling-functions: 

SETUNWIND 

SIGNAL 

SIGNAL_STOP 

The description of these condition-handling-functions is given in Chapter 17. 

Predeclared Macro-Names — The following names are predeclared as macro- 
names: 

%BLISS16 
%BLISS32 
%BLISS36 

The description for each of these macro-names is given in Section 16.2.4. 

Predeclared Supplementary-Function-Names — The following names are 
predeclared as supplementary-function-names: 

CH$ALLOCATION, CH$SIZE 

CH$PTR, CH$PLUS, CH$DIFF 

CH$RCHAR, CH$A_RCHAR, CH$RCHAR_A 

CH$WCHAR, CH$A_WCHAR, CH$WCHAR__A 

CH$MOVE, CH$FILL, CH$COPY 

CH$COMPARE 

CH$EQL, CH$NEQ, CH$LSS, CH$LEQ, CH$GTR, CH$GEQ 

CH$FIND_CH, CH$FIND_NOT_CH, CH$FIND_SUB, CH$FAIL 

CH$TRANSTABLE, CH$TRANSLATE 

All of these are names of functions in the character-handling package, which 
is described in Chapter 20. 

Builtin Machine-Specific-Function Names — Each BLISS dialect provides a 
set of predefined machine-specific-function names that must be individually 
declared BUILTIN wherever they are used as such. The machine-specific- 
functions defined for each dialect are described in the appropriate BLISS 
user's guide. The function names (for all dialects) are included in the listing of 
predefined identifiers given in Appendix A of this manual. 
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A program is made up of object modules that have been linked together to 
form a single executable unit. The object modules that make up the program 
are produced as a result of the translation of a source module by one of the 
translators in the system. For example, the BLISS compiler translates BLISS 
modules into object modules and the FORTRAN compiler translates FOR- 
TRAN programs into object modules. Each translator produces an object 
module with a uniform set of indicators for the linker. The linker uses these 
indicators to allocate the modules and resolve points of communication 
among them. 
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Consider a program that inputs values, sorts them, and then outputs the same 
values in sorted order. This program could consist of a FORTRAN program to 
do input/output and the following BLISS modules: 

MODULE TREESORT (I DENT = '0002') 

BEGIN 

ROUTINE EXCHANGE<F1 fFZ) = 

« » « ? 
GLOBAL ROUTINE TREESORT < F 1 »F2 ) = 

. * < 5 
END 
ELUDOM 

MODULE PROCESS (IDENT = '0002'»MAIN = PROCESS) = 

BEGIN 

EXTERNAL ROUTINE 

INPUT; FORTRAN t 

OUTPUT: FORTRAN* 

TREESORT 5 
ROUTINE PROCESS = 

BEGIN 

PSECT OWN = ALPHA! 

ONN A: VECTORC 100] 5 

INPUT(A) 5 

TREESORT (A f 100) i 

OUTPUT(A) 

END? 
END 
ELUDOM 

The linker links the two object modules produced by a BLISS compiler and 
the FORTRAN object module produced by the FORTRAN compiler to form a 
single unit. Then, execution begins at the specified point. In this case, execu- 
tion begins with the routine PROCESS. 
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Chapter 20 

Character Handling Functions 



A major part of computing is devoted to character handling; that is, the 
manipulation of sequences of characters. Character handling is required for 
the interpretation of user commands, for the preparation of output listings, for 
the management of symbol tables, for the editing of text, and for the mainte- 
nance of files. 

This chapter describes the BLISS functions that are designed for character 
handling. Some of these functions perform a basic operation, such as allocat- 
ing storage for a character sequence, or creating a pointer that can move back 
and forth through a character sequence, or writing (or reading) a character at 
a given position in a character sequence. Other functions perform an opera- 
tion on an entire character sequence, such as moving, copying, comparing, or 
searching the sequence. 

The functions described in this chapter are part of the set of supplementary- 
functions that was introduced in Chapter 5. A call on one of these functions 
usually does not produce a subroutine call; instead, it is compiled into a few 
hardware instructions that are especially designed for character handling. 
These functions provide a way of using these hardware instructions without 
causing a program to be machine-dependent. A program that uses these func- 
tions correctly (and that does not have machine dependence elsewhere) can be 
transported without change to another BLISS target system. 

The first section of this chapter presents the concepts that are necessary for a 
discussion of character handling. The second section defines the character 
handling functions. 
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A discussion of the fundamental concepts of character handling follows. First 
character data is described, and then the operations that are applied to char- 
acter data are summarized. 
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20.1.1 Character Sequence Data 

A character code is a sequence of bits that represents a character. Usually the 
ASCII encoding of characters is used in BLISS. However, as long as a program 
makes consistent use of a given character encoding, it does not matter what 
that encoding is. 

A character position is the storage for a single character code. For a given 
implementation of BLISS, the size of a character position is determined by 
two factors: the requirements of the character set and the organization of the 
computer memory. A program can be written in a way that does not depend 
on the specific character size used by a specific implementation. 

A character position sequence is a portion of storage that is used for one or 
more character positions. Such a sequence has a first and last position. For 
each position except the first, there is a previous position, and for each posi- 
tion except the last, there is a next position. 

A character data segment is a character position sequence that is allocated as 
a single portion of storage. In the simpler applications of character handling, 
it is possible to treat each character data segment as a separate unit, allocated 
in the same way other data segments are. In more advanced applications, a 
single character position sequence may extend across several data segments 
and may be reorganized as program execution proceeds. 

A character pointer is a value that designates a character position. Sometimes 
a character pointer is set to the first character position of a sequence and 
remains there, providing access to the entire sequence. In other cases, a char- 
acter pointer is used to scan back and forth in a sequence, selecting one 
position after another. -A character pointer occupies a full word. It can be 
moved from one fullword to another or can be passed as a parameter of a 
routine, like any other fullword value. However, a character pointer can be 
correctly interpreted only by a character handling function. For example, a 
character pointer must be advanced by the CH$PLUS function, not by the 
"+" operator. 

A null pointer is a returned value that indicates the absence of a valid charac- 
ter pointer. A null pointer results from the unsuccessful search for one or more 
characters within a sequence. The presence of a null pointer can only be 
tested for by a CH$FAIL function, and a null pointer must not be passed to 
any other character function. 

The length of a character position sequence is the number of character posi- 
tions in the sequence. The length of a sequence is not included as part of the 
sequence itself. In order to fully specify a character position sequence, both its 
length and a pointer to its first position must be given. Typically, the parame- 
ters of the character handling functions occur in pairs, a length followed by a 
pointer. 

Character handling can be programmed on two levels. On the simpler level, 
all the data is divided into independent character data segments, and the 
segments are allocated in the usual way for OWN or LOCAL segments. In 
more advanced applications, data may be allocated dynamically, under pro- 
gram control. 
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20.1.2 Character Sequence Operations 

The basic operations of character handling are summarized here. These oper- 
ations are the allocating of storage, creating of a pointer, moving a pointer, 
fetching or storing a character code, and comparing of character sequences. 
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A character data segment is allocated in a special way. Specifically, the 
amount of storage required is expressed in terms of character positions rather 
than longwords, words, or bytes. 

A character pointer is created from a given data segment address. The data 
segment must be one that was allocated as a character sequence segment. The 
character pointer designates the first character position of the sequence. 

A character pointer that designates a given character position is moved for- 
ward by changing it to designate the next character position of the sequence. 
Similarly, a character pointer is moved backward by changing it to designate 
the previous character position of the sequence. A character pointer should 
not be moved beyond the character data segment in which it originated unless 
(1) the programmer is quite sure what lies beyond that segment or (2) the 
programmer intends to move it back into the same segment before using it. 

The contents of a character position must always be fetched or stored by 
means of a character pointer that designates the character position. In con- 
trast, a character pointer can be fetched or stored like any other fullword 
value (by means of the fetch-operator, ".", or the assignment operator, "="). 

Character sequences and character pointers must be compared only by means 
of the character handling functions designed for that purpose. 
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For the purpose of definition, the character handling functions are arranged in 
eight classes, as follows: 

Allocation Functions 
Pointer Functions 
Character-Reading Functions 
Character- Writing Functions 
Sequence-Writing Functions 
Sequence-Comparing Functions 
Sequence-Searching Functions 
Sequence-Translating Functions 

Each class of functions is described in one of the following sections. 

The name of each character handling function consists of the prefix "CH$" 
followed by a mnemonic name; for example, "CH$ALLOCATION" is the 
name of the function that computes the storage that must be allocated for a 
sequence. 

20.2.1 Allocation Functions 

The allocation functions determine the amount of storage required for charac- 
ter data. The function CH$ALLOCATION returns the number of fullwords 
required for a given number of characters. The function CH$SIZE returns the 
number of bits required for a single character. 
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20.2.1.1 Definition — The allocation functions are defined as follows: 

CH$ALLOCATION( n, cs ) 

Interpret n as an unsigned integer (the length of the allocated sequence). 
Interpret cs as an unsigned integer (the character size. ) Imagine a char- 
acter position sequence composed of n character positions, each of which 
occupies cs bits. Return the number of full words that would be required 
for storage of such a character position sequence. 

Default character size. The character-size parameter can be omitted; 
that is, the form CH$ALLOCATION(rc) is permitted. In this case, the 
system default for the character size is used for cs. In BLISS-16 and 
BLISS-32 this default is 8; in BLISS-36, the default is 7. 

CH$SIZE( ptr ) 

Interpret ptr as a pointer to a character position sequence. Return the 
character size for the sequence; that is, return the number of bits occu- 
pied by each character position of the sequence. 

Default character size. The pointer parameter can be omitted; that is, 
the form CH$SIZE() is permitted. In this case, the system default for 
character size is returned. 

The character size, cs, must be a compile-time-constant-expression. 

The CH$ALLOCATION function is a compile-time-constant-expression if the 
length parameter, n, is a compilertime-constant-expression. 

The CH$SIZE function is a compile-time-constant-expression if the pointer 
parameter, ptr, is omitted. 

In BLISS-16 and BLISS-32, a function that specifies a character size other 
than 8 is invalid. Thus the character size is a constant in BLISS-16 and 
BLISS-32. While the character size in BLISS-36 variable, with a range of 1 
through 36 bits, any departure from the default 7-bit character size for ASCII 
encodings or the 6-bit character size for the SIXBIT encoding must be used 
with caution. 

20.2.1.2 Examples — The CH$ALLOCATION function is normally used 
within the VECTOR attribute. An example of this usage is: 

OWN 

S3: VECT0RCCH*ALL0CATI0N(80) 3 5 

This declaration allocates a character data segment for S3 that is composed of 
80 character positions. 

The use of CH$ALLOCATION within the VECTOR attribute is a way of 
extending the BLISS language to handle character data without making ma- 
jor changes in the design of the language. Specifically, the use of the VEC- 
TOR attribute is a way of allocating storage for a character position sequence. 
It follows that storage allocated in this way should not be accessed as a vector, 
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even though that is technically possible. Instead, the storage should always be 
accessed by the character-handling functions in this chapter. 

In fact, the combination of the VECTOR attribute with CH$ALLOCATION 
should be thought of as a single language construct. This point of view can be 
expressed by means of the following macro: 

MACRO 

CH$SEQUENCE(N) = VECTOR C CH$ALLOCAT I ON ( N ) ] li 

Within the scope of this declaration, CH$SEQUENCE can be used as if it 
were a character-sequence attribute. For example, the declaration of S3, given 
several paragraphs earlier, can be written as follows: 

OWN 

S3: CH*SE0UENCEC80] i 

The CH$SEQUENCE macro just given is not a predeclared part of the BLISS 
language. It is given here as a suggested user-declared macro. If it is used in a I 
program, then it must be explicitly declared in that program. 

When the CH$ALLOCATION function is used in the VECTOR attribute (as 
is normally the case), the parameters of CH$ ALLOCATION must be compile- 
time-constant-expressions. This restriction follows from the definition of the 
VECTOR attribute (given in Section 11.4.1), which requires that an expres- 
sion that is an actual parameter of the VECTOR attribute be a compile-time- 
constant-expression. 

The declaration of S3, given above, satisfies this requirement because its 
length parameter is 80 and its character-size parameter is absent. 

In advanced programming applications, CH$ALLOCATION is used with a 
non-constant length. For example, in a program that performs dynamic allo- 
cation of storage for character sequences, CH$ALLOCATION is used to deter- 
mine the amount of storage required. 

20.2.2 Pointer Functions 

The pointer functions create or manipulate character pointers. The CH$PTR 
function returns a character pointer that designates a character position. The 
CH$PLUS function creates a character pointer that is offset by a given num- 
ber of character positions from another character pointer. The CH$DIFF func- 
tion determines the offset between two given character pointers. 

20.2.2.1 Definition — The pointer functions are defined as follows: 

CH$PTR( addr, i, cs ) 

Interpret addr as the address of a data segment (the base address). Inter- 
pret i as a signed integer (the index). Interpret cs as an unsigned integer 
(the character size). Assume that the given segment is a character posi- 
tion sequence that uses cs bits for each character position. Return a 
character pointer to the (i+l)'th character position of the sequence con- 
tained in the segment at addr. 
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Default character size. The character-size parameter can be omitted; 
that is, the form CH$PTR(ac/dr,i) is permitted. In this case, the system 
default is used for the character size. In BLISS-16 and BLISS-32, this 
default is 8; in BLISS-36, the default is 7. 

Default index. When the character-size parameter is omitted, the index 
parameter can also be omitted; that is, the form CH$PTR(ac/c/r) is per- 
mitted. In this case, the system default is used for the character size and 
is used for the index. 

CH$PLUS( ptr, i ) 

Interpret ptr as a pointer into a character position sequence. Interpret i 
as a signed integer (the index.) Suppose that ptr designates the k'th 
character position of the given sequence. Return a pointer that desig- 
nates the (i+k)'th character position of the given sequence. 

CH$DIFF( ptrl, ptr2 ) 

Interpret ptrl and ptr2 as character pointers of the same character size 
(bits per character) pointing into the same character position sequence. 
Suppose the pointers designate the nfth and n2'th character positions, 
respectively, of the given sequence. Return (nl-n2). 

The character size, cs, in a CH$PTR function must be a compile-time-con- 
stant-expression, and in BLISS-16 and BLISS-32 its value must be 8. 

The CH$PTR function is a link-time-constant-expression if addr is a link- 
time-constant-expression and i and cs are, if given, each a compile-time- 
constant-expression . 

In BLISS-16 and BLISS-32 a function that specifies a character size other 
than eight bits is not valid. 

20.2.2.2 Examples — A character data segment is allocated with a name 
whose value is an address. Since a character position sequence must be ac- 
cessed through a character pointer, some means for creating a pointer is 
required. The CH$PTR fills this need. 

An example of the use of the CH$PTR function is: 



LITERAL 




BUFFS I ZE = 80 ; 




OWN 




OADDR: CH$SE0UENCE C BUFFS I Z 


E] f 


OBEGIN t 




oend ; 




OBEGIN = CH$PTR(0ADDR) 5 




OEND = CH$PTR(0ADDR ,BUFFSIZE 


-1 ) ; 



The two assignments set the contents of QBEGIN and QEND to pointers to 
the first and last character positions of the segment QADDR. (Note that 
CH$SEQUENCE is a user-declared macro that was described in Section 
20.2.1.2.) 
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Given a pointer to a character position, the CH$PLUS function can produce a 
modified pointer that designates a character position that is a certain number 
of positions before or after the original position. An example is: 

LITERAL 

BUFFSIZE = 80 i 
OWN 

X: CH$SEQUENCE[BUFFSIZE] » 

PTRi 5 

♦ 4 ♦ 

PTR1 = CH*PTR(X) 5 - 

INCR I FROM TO BUFFSIZE-1 DO 

BEGIN 

»♦♦ (Operation » 1 ) 

PTR1 = CH$PLUS( .PTR1 »1 ) 5 

END? 

This loop evaluates Operation #1 (which is not specified here) BUFFSIZE 
times. During each evaluation, PTR1 designates a different character position 
within X, starting at the first position and advancing by one position each 
time. 

Given two pointers, the number of characters between them can be obtained 
by means of the CH$DIFF function. An example is: 

OWN 

Ms CH*SEQUENCEC 100 3 5 

PTR1 * 

PTR2 > 

N5 
♦ » ♦ 

PTR1 = CH*PTR(M ,25) 5 
PTR2 = CH$PTR(M »75) i 

N = CH*DIFF( .PTRZf PTR1) i 

This program fragment sets N to 50, which is the offset of PTR2 relative to 
PTR1. 

The CH$DIFF function is the only valid way to compare two character 
pointers. Suppose, for example, it is necessary to call the routine REX if the 
pointer contained in X is the same as the pointer contained in Y. This action 
can be programmed as follows: 

IF CH*DIFF( .X».Y) EQL THEN REXO? 

20.2.3 Character-Reading Functions 

Each of the character-reading functions returns a character code. Specifically, 
each function uses a given character pointer to locate a character position, 
and then fetches the character code that is contained in that character posi- 
tion. The functions operate on the given character pointer in different ways: 
CH$RCHAR does not change the pointer, CH$A__RCHAR advances the 
pointer by one character position before fetching a character code, and 
CH$RCHAR A advances the pointer after fetching. 
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20.2.3.1 Definition — The character-reading functions are defined as follows: 

CH$RCHAR( ptr ) 

Interpret ptr as a character pointer. Fetch the contents of the character 
position that is designated by the character pointer. Return the fetched 
value. 

CH$A_RCHAR( addr ) 

Interpret addr as the address of a character pointer. Advance the charac- 
ter pointer to the next character position and then fetch the contents of 
the character position designated by the character pointer. Return the 
fetched value. 

CH$RCHAR_A( addr ) 

Interpret addr as the address of a character pointer. Fetch the contents of 
the character position designated by the character pointer and then ad- 
vance the character pointer to the next character position. Return the 
fetched value. 

It is important to note that the parameter of CH$RCHAR is a character 

pointer, whereas the parameter of CH$A RCHAR and CH$RCHAR A is 

the address of a character pointer. 

20.2.3.2 Examples — For some examples of these functions, consider the 
following program fragment: 

CP = CH$PTR(UPLIT('ABCD')); Creates pointer to sequence. 

CV1 = CH$RCHAR(.CP); Sets CV1 to %C'A\ 

CV2 = CH$A__RCHAR(CP); Sets CV2 to %C'B'. 

CV3 = CH$RCHAR_A(CP); Sets CV3 to %C'B'. 

CV4 = CH$RCHAR(.CP); Sets CV4 to %C'C\ 

20.2.4 Character-Writing Functions 

Each of the character-writing functions stores a character code. Specifically, 
each function uses a given character pointer to locate a character position, 
and then stores a given character-code in that character position. Like the 
character-reading functions, these functions operate on the given character 

pointer in different ways: CH$WCHAR does not change the pointer, CH$A 

WCHAR advances the pointer by one position before storing the character 
code, and CH$WCHAR A advances the pointer after storing. 

20.2.4.1 Definition — The character-writing functions are defined as follows: 

CH$WCHAR( c, ptr ) 

Interpret c as a character code and interpret ptr as a character pointer. 
Store c in the character position designated by the character pointer. Do 
not return a value. 
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CH$A_WCHAR( c, addr ) 

Interpret c as a character code and interpret addr as the address of a 
character pointer. Advance the character pointer to the next character 
position, then store c in the character position designated by the charac- 
ter pointer. Do not return a value. 

CH$WCHAR^_A( c, addr ) 

Interpret c as a character code and interpret addr as the address of a 
character pointer. Store c in the character position designated by the 
character pointer, then advance the character pointer to the next charac- 
ter position. Do not return a value. 

In each of these functions, c must be in a range suitable for use as a character 
code. Since none of these functions return a value, they must not be used in 
contexts that require a value. As with the character-reading functions, the 
parameter of CH$WCHAR is a character pointer, whereas the parameter of 
CH$A_WCHAR and CH$WCHAR__A is the address of a character pointer. 

20.2.4.2 Examples — An example of the use of these functions is the following 
program fragment: 

OWN 

S4: CH$SE0UENCEC5] » . 

P: INITIAL(CH* PTR(54) ) i 
* ♦ ♦ 

CH$WCHAR(XC'P ' » . P) i 
INCR I FROM 1 TO 4 DO 

CH$A_WCHARU,C'Q' »P) 5 

This example fills S4 up with TQQQQ'. 

20.2.5 Sequence-Writing Functions 

Each of the sequence-writing functions sets the contents of a character posi- 
tion sequence. The CH$MOVE function copies a specified number of charac- 
ters from one character position sequence into another. The CH$FILL func- 
tion sets all of the character positions of a sequence to a given character code; 
for example, it can initialize a sequence to all blanks. The CH$COPY function 
is relatively complex; it can copy several separate character sequences into a 
given character position sequence and then fill in any remaining positions 
with a given fill character. Thus a single CH$COPY function acts like a series 
of CH$MOVE functions followed by a CH$FILL function. 

20.2.5.1 Definition — The sequence-writing functions are defined as follows: 

CH$MOVE( n, sptr, dptr ) 

Interpret n as an unsigned integer (the length of both source and destina- 
tion). Interpret sptr and dptr as pointers. Use these pointers to locate two 
character position sequences (the source and the destination, respec- 
tively) . 
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Copy n characters from the source into the destination. That is, copy the 
contents of the first character position of the source into the first charac- 
ter position of the destination, copy the contents of the second character 
position of the source into the second character position of the destina- 
tion, and so on, until n characters have been copied. Return a pointer to 
the (n+l)'th character position of the destination. 

CH$FILL( fill, dn, dptr ) 

Interpret fill as a character code. Interpret dn as an unsigned integer (the 
length of the destination). Interpret dptr as a character pointer. Use the 
pointer to locate the beginning position of a character position sequence 
(the destination). 

Copy fill into the first n character positions of the destination. Return a 
pointer to the (dn+l)'th character position of the destination. 

CH$COPY( snl, sptrl, sn2, sptr2, ..., fill, dn, dptr ) 

Interpret snl, sn2, ..., and dn as unsigned integers (the lengths of the 
sources and the destination). Interpret sptrl, sptr2, ..., and dptr as char- 
acter pointers. Use sptrl, sptr2, ..., and dptr to locate the beginning 
positions of some character position sequences (the first source, the sec- 
ond source, ..., and the destination, respectively). Interpret fill as a char- 
acter code. 

Copy snl character codes from the first source into the first snl character 
positions of the destination, copy sn2 character codes from the second 
source into the next sn2 character positions of the destination, and so on. 
If less than dn characters have been copied, copy the character code fill 
into the remaining character positions of the destination. Return a 
pointer to the (dn+l)'th character position of the destination. 

If the source lengths, snl, sn2, and so on, are all compile-time-constant- 
expressions, then snl+sn2+... must not be greater than dn. If the lengths of 
the sources are not all compile-time-expressions, then the snl+sn2+... can 
exceed dn, but any character code that would be stored in a character position 
beyond the end of the destination is discarded. 

The destination of a CH$MOVE function must not overlap the source; that is, 
the two sequences must not have *Jiy character positions in common. Simi- 
larly, the destination of the CH$COPY function must not overlap any of its 
sources. 

20.2.5.2 Examples — The sequence-writing functions are a convenience be- 
cause they combine in a single function what would require many 
CH$WCHAR functions. More important, perhaps, they contribute to effi- 
ciency by making use of the special hardware instructions especially designed 
for moving character sequences. 
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An example of the use of the CH$MOVE and CH$FILL functions is: 

OWN 

X: CH$SE0UENCEC20] t 

p; 

BIND 

S = UPLIK 'ABCD ' ) 5 

♦ ♦ ♦ 

P = CH$PTR(X> 1 

INCR I FROM 1 TO a DO 

BEGIN 

P = CH$MOUE(.I, CH$PTR(S)» . P)5 

P = CH$FILL( %C '-' t 5- . I » . P) 5 

end; 
At the end of this fragment, the contents of X is: 

'A AB ABC- -ABCD- ' 

The final value of P is a pointer to the twenty-first character position of X; 
that is, the unspecified character position that follows the last character posi- 
tion of X. 

An example of the use of the CH$COPY function is: 

OWN 

ALPHA; CH$SEQUENCEE 103 5 
BIND 

Q = UPLIK 'ABCDEFGH' ) i 

♦ ♦ ♦ 

CH$C0PY( 

3 t CH*PTR(0 »5) t 

5 , CH*PTR(Q) » 

7,C ' ' t 

10 » CH*PTR(ALPHA) ) 5 

At the end of this program fragment, the contents of ALPHA is: 

'FGHABCDE 

This example assigns a relatively complicated value to ALPHA by means of a 
single function call. 

The CH$COPY function does not do anything that cannot be done by a 
combination of the CH$MOVE and CH$FILL functions. For example, the 
previous program fragment could be replaced by: 

OWN 

ALPHAS CH$SEQUENCEC 10] t 

PA 5 
BIND 

= UPLIK 'ABCDEFGH' ) 5 

PA = CH*PTR( ALPHA) i 

PA = CH*M0VE<3» CH$PTR(Q»5)» .PA) 5 
PA = CH*M0VE(5» CH$PTR(0) , , PA)5 
CH$FILL('/,C ' ' , 2 * .PA) 5 
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This version is less compact and less efficient than the version that uses 
CH$COPY. The use of PA as temporary storage for the pointer could be 
eliminated by a nesting of function calls; nevertheless, this version would 
require three function calls to replace the single call on CH$COPY. 

20.2.6 Sequence-Comparing Functions 

Each of the sequence-comparing functions compares the contents of one char- 
acter position sequence to another. With the exception of CH$COMPARE, 
these functions return 1 if the comparison is satisfied and return otherwise; 
thus they serve character sequences in the same way relational operators serve 
integer and address values (see Section 5.1.4.5). If one of the character 
sequences is shorter than the other, it is (for purposes of the comparison only) 
extended by adding "fill characters" at the end. 

The CH$EQL function determines whether or not the two given sequences are 
identical, and the CH$NEQ function is the negation of CH$EQL. The re- 
maining-sequence comparing functions depend on the ordering of character 
sequences. That ordering is determined by rules similar to those for arranging 
the words and phrases in a dictionary. The CH$LSS function determines 
whether or not the first parameter occurs before the second parameter in the 
ordering of sequences. The CH$LEQ, CH$GTR, and CH$GEQ functions are 
similarly defined. 

The CH$COMPARE function determines whether the first parameter occurs 
before, is equal to, or occurs after the second parameter. The function returns 
-1, 0, or 1, respectively. This function can be used as a case-index in a case- 
expression to provide, in a clear and efficient way, an action for each of the 
three possible relations between two sequences. 

20.2.6.1 Definition — The sequence-comparing functions are defined as 
follows: 

CH$xxx( nl, ptrl, n2, ptr2, fill ) 

In this definition, "CH$xxx" stands for any one of the seven function 
names given in the table below. Interpret nl and n2 as unsigned integers 
(the lengths of the given sequences). Interpret ptrl and ptr2 as character 
pointers. Use these pointers to locate the beginning positions of two char- 
acter position sequences. Interpret fill as a character code. 

If nl is not equal to n2 (so that the sequences are of different lengths), 
treat the shorter one as if it had sufficient additional character positions 
and each additional character position contained fill. 

Look through the two sequences in parallel, one character position at a 
time. That is, select the first position of each sequence, then select the 
second position of each sequence, and so on. Proceed in this manner until 
a position is selected that contains one character code for one sequence 
and a different character code for the other. If no such position is found 
(because the sequences are identical), proceed to the last position of the 
sequences. 



20-12 Character Handling Functions 



Call the character codes in the selected positions of the first and second 
sequence cl and c2, respectively. These character codes are integers, and 
are subject to arithmetic comparison. On the basis of the function name 
and the character codes cl and c2, obtain a value from the following 
table: 



Function 
Name 


cl less 
than c2 


cl equal 
to c2 


cl greater 
than c2 


CH$EQL 
CH$NEQ 



1 


1 




1 


CH$LSS 
CH$LEQ 


1 
1 



1 






CH$GTR 
CH$GEQ 








1 


1 
1 


CH$COMPARE 


-1 





1 



Return the value thus obtained. 

Default fill character. The last parameter can be omitted; that is, the 
form CH$(nl,ptrl,n2,ptr2) is permitted. In this case, is used as the 
value of fill. 

20.2.6.2 Examples — As the basis for some examples, consider the following 
declarations: 

BIND 

P_ALPHA = CH$PTR(UPLIT( 'ALPHA' )) t 

P_BETA = CH$PTR(UPLIT( 'BETA' ) ) » 

P-BEAR = CH$PTR(UPLIT< 'BEAR' ) ) » 

P_BE = CH$PTR(UPLIT( 'BE ' ) ) 5 

The examples are: 

1. CH$LSS(5, P_ALPHA, 4, P_BETA) 

The evaluation of this example is especially simple. When correspond- 
ing characters are compared, it is determined that the first characters of 
the parameters, 'A' and 'B', are different. Since the ASCII code for 'A' is 
less than the ASCII code for 'B', the value of the function is 1. 

2. CH$GTR(4, P__BETA, 4, P_BEAR) 

In the evaluation of this example, it is determined that the third char- 
acters of the parameters 'T' and 'A' are different. Since the ASCII code 
for 'T' comes after the ASCII code for 'A', the value of the function is 1. 

3. CH$GTR(4, P_BEAR, 2, P_BE) 

In the evaluation of this example, the fill character added to the second 
parameter plays a decisive role. That is, the first two characters of the 
parameters are the same, so it is 'A' and the fill character that are 
different. The default fill character is 0. Since the ASCII code for 'A' is 
greater than 0, the value of the function is 1 . 
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4. CH3GTR(4, P_BEAR, 2, P_BE, 127) 

In this example, the fill character is given explicitly as 127, which is 
equal to the highest ASCII code. Since the ASCII code for 'A' is less 
than 127, the value of the function is 0. 

5. CH$COMPARE(5, P_ALPHA, 4, P_BETA) 

Since the value of the ASCII code for 'A' is less than the ASCII code for 
*B\ the value of the function is -1. 



20.2.7 Sequence-Searching Functions 

The sequence-searching functions are used to find a single character or a 
sequence of characters within a larger character sequence. Searching is always 
done from from left to right (from the first character position to the last). 

The CH$FIND CH function looks for a character position that contains a 

given character, whereas the CH$FIND NOT CH looks for a character 

position that contains anything but a given character. The CH$FIND SUB 

function looks for a given sequence of characters. 

If the desired character or character sequence cannot be found by these func- 
tions a null pointer is returned. A CHSFAIL function then determines whether 
the returned pointer is or is not a null pointer; also, be aware that a null 
pointer must not be passed to any CH$ function except CH$FAIL. 

20.2.7.1 Definition — The sequence-searching functions are defined as 

follows: 

CH$FIND__CH( n, ptr, char ) 

Interpret n as an unsigned integer (the length of the context). Interpret 
ptr as a character pointer. Interpret char as a character code. Use ptr to 
locate a character sequence, the context. 

Search the first n character positions of the context for a position that 
contains char, and return a pointer to that position. If no such character 
position is found, return the null pointer. 

CH$FIND_NOT_CH( n, ptr, char ) 

Proceed as for CH$FIND CH, above. However, search the given se- 
quence for a position whose contents are not equal to char. 

CH$FIND_SUB( en, cptr, pn, pptr ) 

Interpret en and pn as unsigned integers (the lengths of the context and 
pattern, respectively). Interpret cptr and pptr as character pointers. Use 
these pointers to locate two character position sequences, the context and 

the pattern. 

Start at the first character position of the context and search for a se- 
quence of positions that contains the pattern. If such a sequence is found, 
return a character pointer to the first position of the sequence. Otherwise, 
return the null pointer. 
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CH$FAIL( ptr ) 

Interpret ptr as a pointer. If the pointer is the null pointer, then return 1 ; 
otherwise, return 0. 

20.2.7.2 Examples — As an example of the use of the CH$FIND__CHAR and 
CH$FIND_NOT_CHAR functions, consider the following routine: 

ROUTINE FIND_W0RD<N » LINE): NOUALUE - 
BEGIN 
EXTERNAL ROUTINE 

PROCESS-WORD ? 
OWN 

LE t 

RE ; 
LE = CH$FIND_N0T_CH( .N > .LINE. 7..C ' ')! 
RE = CH$FIND_CH( .N--CH$DIFF( ,LE , .LINE) , .LE, IC ! ')! 
PROCESS-WORD ( CH$DIFF ( . RE > . LE ) , . LE ) i 
END ; 

This routine finds the first full "word" in a given line of text. For purposes of 
this routine, a "word" is any sequence of characters that does not contain a 
space. 

The two parameters of the routine are defined as follows: 

.N is the number of positions in the character position sequence that 

contains the given text. 

.LINE is a pointer to the first position of the character position sequence 
that contains the given text. 

The first assignment in the routine sets .LE to point to the first character of 
the word. The second assignment sets .RE to point to the first space after 
the word. Finally, a routine that processes the word is called; that routine, 
PROCESS—WORD, is not specified here. 

20.2.8 Sequence-Translating Functions 

The sequence-translating functions are used to translate a character sequence 
from one encoding to another. The CH$TRANSTABLE function builds a 
table that controls the translation. The CH$TRANSLATE function uses the 
table to translate a given sequence into the new encoding. 

These functions make use of a character translation table. The table is, itself, 
a character position sequence. Suppose, for example, the contents of the first 
character position of such a table is 7; that means that a character code whose 
value is will be translated to 7 by the table. 

The table contains one position for each character-code value in the source 
character-code set. For example, if the source character sequence is ASCII 
encoded, then the translation table must contain 128 positions, one for each 
value in the (7-bit) ASCII character-code set. The CH$TRANSLATE func- 
tion essentially uses the value of a given source character position as a zero- 
based index into the table, from which it obtains the corresponding destina- 
tion code value. 
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20.2.8.1 Definition — The contents of a character translation table is given as 
a parameter of the CH$TRANSTABLE function. The syntax of this parame- 
ter is: 



translation-string 


translation-item ,... 


translation-item 


( translation-code ) 
( REP replicator OF ( translation-string ) ) 


replicator 


compile-time-constant-expression 


translation-code 


single-character-literal 



The sequence- translating functions are defined as follows: 

CH$TRANSTABLE( ts ) 

(The symbol ts represents a translation-string, which is described 
above.) Create the translation table specified by ts and place it in the 
current PLIT program section. Return the address of the translation 
table. 

CH$TRANSLATE( tab, sn, sptr, fill, dn, dptr ) 

Interpret tab as an address and use it to locate a character translation 
table. Interpret sn and dn as unsigned integers (the lengths of the source 
and the destination, respectively). Interpret sptr and dptr as pointers 
and use them to locate the beginning positions of two character position 
sequences (the source and the destination. ) Interpret fill as a character 
code. 

Let n be sn or dn (the length of the source or the destination), whichever 
is smaller. Perform the following steps for i = 1, 2, ..., n: fetch the 
contents of the fth character position of the source, and call its value c. 
Fetch the contents of character position c of the character translation 
table (whose first position is numbered 'zero'), and call the value tc. 
Store tc in the fth character position of the destination. 

If sn is greater than dn (that is, the source is longer than the destination), 
then ignore the last sn-dn positions of the source. If sn is less than dn, 
then set the last (dn-sn) character positions of the destination to fill. 
Observe that the fill character code is not translated. 

Return a pointer to the (dn+lYth character position of the destination. 

The CH$TRANSTABLE function is always a compile-time-constant- expres- 
sion. In fact, the table is created and allocated by the compiler in the same 
way a PLIT is created and allocated. The destination of a call on the 
CH$TRANSLATE function must not overlap the source; that is, the two 
sequences must not have any character positions in common. 
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20.2.8.2 Examples — As an example of the use of the sequence-translating 
functions, consider the following routine: 

ROUTINE R(N» LINE, W0RK_BUF): NOVALUE = 
BEGIN 
BIND 

TAB = 

CH$TRANSTABLE( 
REP 32 OF CJGC '*' ) » 
7,0 ' ' t 

REP 10 OF (ZC'*')» 
%C ' + ' f 

REP 1 OF (ZC '* ' ) » 
XC- ' t 

REP 2 OF {%€'*')> 

'Jf,C ' ' » XC ' 1 ' » 5f.C ' 2 ' » 'Z.C ' 3 ' » XC ' a ' t 
1C5' t %C'B' t ZC'7't IC'B' > XC'9' t 
REP 70 OF (1C* ' ) ) 5 

4 ♦ ♦ 

CH$TRANSLATE( 

TAB t 

.N t .LINE » 

> 

,N » ,W0RK_BUF) 5 

star = ch$find_ch( .n » «w0rk_buf» %c '* ' ) 5 
if ch$fail( .star) 

then pr0cess( *n > .line) 

else err0r(.n» .line* ch$d i ff ( , star , ♦w0rk_buf))5 
end; 

This routine performs a preliminary check of a given line of text that is 
expected to represent one or more integers. For purposes of this routine, the 
presence of any character other than a space, a sign, or a digit makes the line 
invalid. If the line is valid, then a routine to further process the line if called; 
that routine, PROCESS, is not specified here. Otherwise, a routine to handle 
an invalid line, ERROR, also not specified here, is called. 

The three parameters of the routine are defined as follows: 

.N is the number of positions in the character position se- 

quence that contains the given text. 

.LINE is a pointer to the first position of the character position 

sequence that contains the given text. 

.WORK BUF is a pointer to the first character position of a work area 

that is to receive the translated sequence. 

A step-by-step description of the routine R follows: 

1. A translation table is defined and its address is bound to TAB. The 
table is designed to leave unchanged any space, sign, or decimal digit, 
but to replace any other character with a '*'. 

2. The given character position sequence is translated. If it is valid, it is 
unchanged. If it is invalid, each invalid character is replaced by an 
asterisk. 

3. The translated sequence is searched for an asterisk, and the resulting 
pointer is assigned to STAR. 
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4. The pointer in STAR is checked by means of CH$FAIL. If it is null, 
then no asterisk was found and the text is passed to the routine PRO- 
CESS. If the pointer is not null, the line is passed to the error routine 
together with the index of the first invalid character. 

This program fragment is relatively complicated, but it is very efficient. With- 
out the translating functions, some method of checking individually for each 
of the valid characters would be required. 
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A predefined identifier is an identifier that has a special meaning in one or 
more dialects of BLISS. For example, "IF" indicates the beginning of a condi- 
tional-expression, and "MAXU" designates the "unsigned maximum" stan- 
dard-function. 

The predefined identifiers are classified as keywords and predefined names. 
Each keyword is either reserved or unreserved, and each predefined name is 
either predeclared or builtin. Thus there are four kinds of predefined identi- 
fiers. 

The use of a predefined identifier as an explicitly-declared name is more or 
less restricted, depending on the classification of the identifier. The restric- 
tions are: 

• A reserved keyword must not be used as an explicitly-declared name 
under any circumstances. 



• 



An unreserved keyword can be used freely as an explicitly-declared name, 
just as if it were not a predefined identifier. The only disadvantage is that 
a human reader may be confused to see a familiar BLISS keyword (such 
as MAIN, for example) being used as an explicitly-declared name. 

• A predeclared name can be used as an explicitly-declared name. How- 
ever, such a use makes it impossible to use the name in its predefined 
sense within the scope of the explicit declaration. For example, wherever 
ABS is explicitly declared (for example, as a data segment name), it 
cannot be used as the name of the absolute value standard-function. 

• A builtin name must always appear in an explicit declaration. If it is 
declared by a builtin-declaration, then it has its predefined meaning; 
otherwise, it has the meaning given it by the explicit declaration, just as 
if it were not a predefined identifier. 

These restrictions can be summarized as follows: In choosing a name, never 
use a reserved keyword and avoid the use of any predefined name if its use 
could cause confusion. 
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As the BLISS language grows, new predefined identifiers will be added to the 
language. In fact, the list given on the following pages includes not only those 
identifiers that are predefined in the versions of BLISS described in this 
manual, but also a number of identifiers that will be predefined in later 
versions of BLISS. 

A complete list of the BLISS keywords and predeclared names follows. The 
applicable dialects are indicated by parenthesized numbers in the classifica- 
tion column: 



Identifier 


Classification 


Usage 


ABS 


predeclared name 


standard-function 


ABSOLUTE 


unreserved keyword(16,32) 


addr.-mode, object-option 


ACTUALCOUNT 


builtin name 


linkage-function 


ACTUALPARAMETER 


builtin name 


linkage-function 


ADDRESSING_MODE 


reserved keyword 


addr.-mode-attr., -switch 


ALIGN 


reserved keyword 


alignment-attribute 


ALWAYS 


reserved keyword 


select-label 


AND 


reserved keyword 


operator-expression 


AP 


builtin name(32,36) 


register-name 


ARGPTR 


builtin name 


linkage-function 


ASSEMBLY 


unreserved keyword 


list-option 


BEGIN 


reserved keyword 


block 


BINARY 


unreserved keyword 


list-option 


BIND 


reserved keyword 


bind-declaration 


BIT 


reserved keyword 


(Future BLISS) 


BITVECTOR 


predeclared name 


structure-name 


BLISS 


predeclared name 


linkage-name 


BLISS10 


predeclared name(36) 


environment-option 


BLISS10_OTS 


unreserved keyword(36) 


environ ment-option 


BLISS16 


unreserved keyword 


language-name 


BLISS32 


unreserved keyword 


language-name 


BLISS36 


unreserved keyword 


language-name 


BLISS36C 


predeclared name(36) 


linkage-name 


BLISS36C—OTS 


unreserved keyword(36) 


environment-option 


BLOCK 


predeclared name 


structure-name 


BLOCKVECTOR 


predeclared name 


structure-name 


BUILTIN 


reserved keyword 


builtin-declaration 


BY 


reserved keyword 


indexed-loop 


BYTE 


reserved keyword 


allocation-unit 


CALL 


unreserved key word( 16,32) 


linkage-type 


CASE 


reserved keyword 


case-expression 


CH$A__RCHAR 


predeclared name 


supplementary-function 


CH$A_WCHAR 


predeclared name 


supplementary-function 


CH$ALLOCATION 


predeclared name 


supplementary-function 


CH$COMPARE 


predeclared name 


supplementary-function 


CH$COPY 


predeclared name 


supplementary-function 


CH$DIFF 


predeclared name 


supplementary-function 


CH$EQL 


predeclared name 


supplementary-function 
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Identifier 


Classification 


Usage 


CH$FAIL 


predeclared name 


supplementary-function 


CH$FILL 


predeclared name 


supplementary-function 


CH$FIND_CH 


predeclared name 


supplementary-function 


CH$FIND_NOT__CH 


predeclared name 


supplementary-function 


CH$FIND_SUB 


predeclared name 


supplementary-function 


CH$GEQ 


predeclared name 


supplementary-function 


CH$GTR 


predeclared name 


supplementary-function 


CH$LEQ 


predeclared name 


supplementary-function 


CH$LSS 


predeclared name 


supplementary-function 


CH$MOVE 


predeclared name 


supplementary-function 


CH$NEQ 


predeclared name 


supplementary-function 


CH$PLUS 


predeclared name 


supplementary-function 


CH$PTR 


predeclared name 


supplementary-function 


CH$RCHAR 


predeclared name 


supplementary-function 


CH$RCHAR_A 


predeclared name 


supplementary-function 


CH$SIZE 


predeclared name 


supplementary-function 


CH$TRANSLATE 


predeclared name 


supplementary-function 


CH$TRANSTABLE 


predeclared name 


supplementary-function 


CH$WCHAR 


predeclared name 


supplementary-function 


CH$WCHAR_A 


predeclared name 


supplementary-function 


CLEARSTACK 


unreserved keyword(16,36) 


linkage-option 


CODE 


unreserved keyword 


module-switch 


CODECOMMENT 


reserved keyword 


codecomment block 


COMMENTARY 


unreserved keyword 


list-option 


COMPILETIME 


reserved keyword 


compiletime-declaration 


CONCATENATE 


unreserved keyword 


psect-attribute 


DEBUG 


unreserved keyword 


module-switch 


DECR 


reserved keyword 


indexed-loop 


DECRA 


reserved keyword 


indexed-loop 


DECRU 


reserved keyword 


indexed-loop 


DO 


reserved keyword 


loop-expression 


ELSE 


reserved keyword 


conditional-expression 


ELUDOM 


reserved keyword 


module 


EMT 


unreserved keyword! 16) 


linkage-option 


ENABLE 


reserved keyword 


enable-declaration 


END 


reserved keyword 


block 


ENTRY 


unreserved keyword (36) 


module-switch 


ENVIRONMENT 


unreserved keyword(36) 


module-switch 


EQL 


reserved keyword 


operator-expression 


EQLA 


reserved keyword 


operator-expression 


EQLU 


reserved keyword 


operator-expression 


EQV 


reserved keyword 


operator-expression 


ERRS 


unreserved keyword 


switch-item, module-switch 


EXECUTE 


unreserved keyword 


psect-attribute 


EXITLOOP 


reserved keyword 


exitloop-expression 


EXPAND 


unreserved keyword 


list-option 


EXTENDED 


unreserved keyword(36) 


environment-option 
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Identifier 


Classification 


Usage 


EXTERNAL 


reserved keyword 


decl.; addr. -mode-switch 


FIELD 


reserved keyword 


field-decl., -attribute 


FORTRAN 


predeclared name(16,32) 


linkage-name 


FORTRAN_FUNC 


predeclared name 


linkage-name 


FORTRAN__SUB 


predeclared name 


linkage-name 


FORWARD 


reserved keyword 


data-, routine-declaration 


FP 


builtin name(32,36) 


register-name 


FROM 


reserved keyword 


indexed-loop, case-exp. 


F10 


predeclared name(36) 


linkage-name 


GENERAL 


unreserved keyword(32) 


addressing- mode 


GEQ 


reserved keyword 


operator-expression 


GEQA 


reserved keyword 


operator-expression 


GEQU 


reserved keyword 


operator-expression 


GLOBAL 


reserved keyword 


decl., linkage-opt., psect-attribute 


GTR 


reserved keyword 


operator-expression 


GTRA 


reserved keyword 


operator-expression 


GTRU 


reserved keyword 


operator-expression 


IDENT 


unreserved keyword 


module-switch 


IF 


reserved keyword 


cond itional-expression 


INCR 


reserved keyword 


indexed-loop 


INCRA 


reserved keyword 


indexed-loop 


INCRU 


reserved keyword 


indexed-loop 


INDIRECT 


unreserved keyword(36) 


addressing-mode 


INITIAL 


reserved keyword 


initial-attribute 


INRANGE 


reserved keyword 


case-label 


INTERRUPT 


unreserved keyword( 16,32) 


linkage-type 


IOPAGE 


reserved keyword 


(Future BLISS) 


IOT 


unreserved keyword(16) 


linkage-type 


JSB 


unreserved keyword(32) 


linkage-type 


JSR 


unreserved keyword(16) 


linkage-type 


JSYS 


unreserved keyword(36) 


linkage-type 


KEYWORDMACRO 


reserved keyword 


keyword-macro-declaration 


KA10 


unreserved keyword(36) 


environment-option 


KI10 


unreserved keyword (36) 


environment-option 


KL10 


unreserved keyword(36) 


environ ment-option 


KS10 


unreserved keyword (36) 


environment-option 


LABEL 


reserved keyword 


label-declaration 


LANGUAGE 


unreserved keyword 


switch-item, module-switch 


LEAVE 


reserved keyword 


leave-expression 


LEQ 


reserved keyword 


operator-expression 


LEQA 


reserved keyword 


operator-expression 


LEQU 


reserved keyword 


operator-expression 


LIBRARY 


reserved keyword 


list-option, library-decl. 


LINKAGE 


reserved keyword 


switch, linkage-declaration 
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Identifier 


Classification 


Usage 


LINKAGE_REGS 


unreserved keyword (36) 


linkage-option 


LIST 


unreserved keyword 


switch-item, module-switch 


LITERAL 


reserved keyword 


literal-declaration 


LOCAL 


reserved keyword 


local-decl., psect-attr. 


LONG 


reserved keyword 


allocation-unit 


LONG_RELATIVE 


unreserved keyword(32) 


addressing-mode 


LSI11 


unreserved keyword(16) 


environment-option 


LSS 


reserved keyword 


operator-expression 


LSSA 


reserved keyword 


operator-expression 


LSSU 


reserved keyword 


operator-expression 


MACRO 


reserved keyword 


macro-declaration 


MAIN 


unreserved keyword 


module-switch 


MAP 


reserved keyword 


map-declaration 


MAX 


predeclared name 


standard-function 


MAXA 


predeclared name 


standard-function 


MAXU 


predeclared name 


standard-function 


MIN 


predeclared name 


standard-function 


MINA 


predeclared name 


standard-function 


MINU 


predeclared name 


standard-function 


MOD 


reserved keyword 


operator-expression 


MODULE 


reserved, keyword 


module 


NEQ 


reserved keyword 


operator-expression 


NEQA 


reserved keyword 


operator-expression 


NEQU 


reserved keyword 


operator-expression 


NOASSEMBLY 


unreserved keyword 


list-option 


NOBINARY 


unreserved keyword 


list-option 


NOCODE 


unreserved keyword 


module-switch 


NOCOMMENTARY 


unreserved keyword 


list-option 


NODEBUG 


unreserved keyword 


module-switch 


NODEFAULT 


unreserved keyword 


psect-attribute 


NOERRS 


unreserved keyword 


switch-item, module-switch 


NOEXECUTE 


unreserved keyword 


psect-attribute 


NOEXPAND 


unreserved keyword 


list-option 


NOINDIRECT 


unreserved keyword(36) 


addressing- mode 


NOLIBRARY 


unreserved keyword 


list-option 


NONEXTERNAL 


unreserved keyword(32) 


addressing-mode-switch 


NOOBJECT 


unreserved keyword 


list-option 


NOOPTIMIZE 


unreserved keyword 


switch-item, module-switch 


NOPIC 


unreserved keyword 


psect-attribute 


NOPRESERVE 


unreserved keyword 


linkage-option 


NOREAD 


unreserved keyword 


psect-attribute 


NOREQUIRE 


unreserved keyword 


list-option 


NOSAFE 


unreserved keyword 


switch-item, module-switch 


NOSHARE 


unreserved keyword 


psect-attribute 


NOSOURCE 


unreserved keyword 


list-option 


NOSYMBOLIC 


unreserved keyword 


list-option 


NOT 


reserved keyword 


operator-expression 
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Identifier 


Classification 


NOTRACE 


unreserved keyword 


NOTUSED 


unreserved keyword (32) 


NOUNAMES 


unreserved keyword 


NOVALUE 


reserved keyword 


NOWRITE 


unreserved keyword 


NOZIP 


unreserved keyword 


NULLPARAMETER 


builtin name( 16,32) 


OBJECT 


unreserved ke>word 


OF 


reserved keyword 


OPTIMIZE 


unreserved keyword 


OPTLEVEL 


unreserved keyword 


OR 


reserved keyword 


ORIGIN 


unreserved keyword(36) 


OTHERWISE 


reserved keyword 


OTS 


unreserved keyword(36) 


OTS—L1NKAGE 


unreserved keyword(36) 


OUTRANGE 


reserved keyword 


OVERLAY 


unreserved keyword 


OWN 


reserved keyword 


PC 


builtin name( 16,32) 


PIC 


unreserved keyword 


PLIT 


reserved keyword 


PORTAL 


unreserved keyword(36) 


PRESERVE 


unreserved keyword 


PRESET 


reserved keyword 


PSECT 


reserved keyword 


PS_INTERRUPT 


unreserved keyword (36) 


PUSHJ 


unreserved keyword(36) 


READ 


unreserved keyword 


RECORD 


reserved keyword 


REF 


reserved keyword 


REGISTER 


reserved keyword 


RELATIVE 


unreserved keyword(16) 


RELOCATABLE 


unreserved keyword(16) 


REP 


reserved keyword 


REQUIRE 


reserved keyword 


RETURN 


reserved keyword 


ROUTINE 


reserved keyword 


RSX__AST 


unreserved keyword(16) 


RTT 


unreserved keyword(16) 


RO 


builtin name( 16,32) 


Rl 


builtin name( 16,32) 


R2 


builtin name(16,32) 


R3 


builtin name(16,32) 


R4 


builtin name( 16,32) 


R5 


builtin name(16,32) 


R6 


builtin name(32) 



Usage 

list-option 

linkage-option 

switch-item, module-switch 

novalue-attribute 

psect-attribute 

switch-item, module-switch 

linkage-function 

list-option, module-switch 

case-, select-exp; plit 

switch-item, module-switch 

module-switch 

operator-expression 

psect-attribute 

select-label 

module-switch 

module-switch 

case-label 

psect-attribute 

own-declaration 

register-name 

psect-attribute 

plit 

linkage-option 

linkage-option 

preset-attribute 

psect-decl., -allocation 

linkage-type 

linkage-type 

psect-attribute 

(Future BLISS) 

structure-attribute 

register-, linkage-decl. 

addressing-mode 

object-option 

plit 

list-opt., require-decl. 

return-expression 

routine-declaration 

linkage-type 

linkage-option 

register-name 

register-name 

register-name 

register-name 

register-name 

register-name 

register-name 
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Identifier 


Classification 


R7 


builtin name(32) 


R8 


builtin name(32) 


R9 


builtin name(32) 


RIO 


builtin name(32) 


Rll 


builtin name(32) 


SAFE 


unreserved keyword 


SELECT 


reserved keyword 


SELECTA 


reserved keyword 


SELECTONE 


reserved keyword 


SELECTONEA 


reserved keyword 


SELECTONEU 


reserved keyword 


SELECTU 


reserved keyword 


SET 


reserved keyword 


SETUNWIND 


predeclared name 


SHARE 


unreserved keyword 


SHOW 


reserved keyword 


SIGN 


predeclared name 


SIGNAL 


predeclared name 


SIGNAL_STOP 


predeclared name 


SIGNED 


reserved keyword 


SKIP 


unreserved keyword(36) 


SOURCE 


unreserved keyword 


SP 


builtin name 


STACK 


unreserved keyword(36) 


STACKLOCAL 


reserved keyword 


STANDARD 


unreserved keyword 


STANDARD—OTS 


unreserved keyword(36) 


STRUCTURE 


reserved keyword 


SWITCHES 


reserved keyword 


SYMBOLIC 


unreserved keyword 


Til 


unreserved-key word( 16) 


TES 


reserved keyword 


THEN 


reserved keyword 


TO 


reserved keyword 


TOPS10 


unreserved keyword(36) 


TOPS20 


unreserved keyword(36) 


TRACE 


unreserved keyword 


TRAP 


unreserved keyword(16) 


TYPEPRESENT 


builtin name 


UNAMES 


unreserved keyword 


UNDECLARE 


reserved keyword 


UNSIGNED 


reserved keyword 


UNTIL 


reserved keyword 


UPLIT 


reserved keyword 


VALUECBIT 


unreserved keyword (16) 


VECTOR 


predeclared name 



Usage 

register-name 
register-name 
register-name 
register-name 
register-name 

switch-item, module-switch 

select-expression 

select-expression 

select-expression 

select-expression 

select-expression 

select-expression 

case-, select-expression; field-declaration 

condition-handling-function 

psect-attribute 

(Future BLISS) 

standard-function 

condition-handling-function 

condition-handling-function 

extension-, range-attribute 

linkage-option 

list-option 

register-name 

environment-option 

stacklocal-declaration 

linkage-declaration 

environment-option 

structure-decl., switch 

switchesdeclaration 

list-option 

environment-option 

case-, select-expression; field-declaration 

conditional-expression 

loop, case-expression, select-label 

environment-option 

environment-option 

list-option 

linkage-type 

(Future BLISS) 

switch-item, module-switch 

undeclare-declaration 

extension-, range-attribute 

loop-expression 

plit 

linkage-option 
structure-name, psect-attr. 
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Identifier 


Classification 


Usage 


VERSION 


unreserved keyword 


switch-item, module-switch 


VOLATILE 


reserved keyword 


volatile-attribute 


WEAK 


reserved keyword 


weak-attribute 


WHILE 


reserved keyword 


loop-expression 


WITH 


reserved keyword 


leave-expression 


WORD 


reserved keyword 


allocation-unit 


WORD_RELATIVE 


unreserved keyword 


addressing-mode 


WRITE 


unreserved keyword 


psect-attribute 


XOR 


reserved keyword 


operator-expression 


ZIP 


unreserved keyword 


switch-item, module-switch 


$CODE$ 


predeclared name 


psect-name 


$GLOBAL$ 


predeclared name 


psect-name 


$HIGH$ 


predeclared name(36) 


psect-name 


$LOW$ 


predeclared name(36) 


psect-name 


$OWN$ 


predeclared name 


psect-name 


$PLIT$ 


predeclared name 


psect-name 


f 7 ALLOCATION 


reserved keyword 


allocation-function 


f VASCIC 


reserved key word( 16,32) 


string-literal 


f 7ASCID 


reserved keyword 


string-literal 


'V ASCII 


reserved keyword 


string-literal 


'rASCIZ 


reserved keyword 


string-literal 


'7ASSIGN 


reserved keyword 


calculation-function 


'rB 


reserved keyword 


integer-literal 


n.BUSS 


reserved keyword 


compiler-state-function 


'7BLISS16 


reserved keyword 


predeclared macro 


'7BLISS32 


reserved keyword 


predeclared macro 


'7BLISS36 


reserved keyword 


predeclared macro 


f rBPADDR 


reserved keyword 


predeclared literal 


'VBPUNIT 


reserved keyword 


predeclared literal 


'fBPVAL 


reserved keyword 


predeclared literal 


r r .c 


reserved keyword 


integer-literal 


'VCHAR 


reserved keyword 


string-function 


f rCHARCOUNT 


reserved keyword 


string-function 


f rCOUNT 


reserved keyword 


macro-function 


f ;rCTCE 


reserved keyword 


exp-test-function 


f ;rD 


reserved keyword 


float-literal 


^DECIMAL 


reserved keyword 


integer-literal 


^DECLARED 


reserved keyword 


compiler-state-function 


f 7E 


reserved keyword 


float-literal 


r rELSE 


reserved keyword 


lexical-conditional 


TERROR 


reserved keyword 


advisory-function 


r rERRORMACRO 


reserved keyword 


advisory-function 
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Identifier 


Classification 


Usage 


'7EXACTSTRING 


reserved keyword 


string-function 


r (EXITITERATION 


reserved keyword 


macro-function 


'rEXITMACRO 


reserved keyword 


macro-function 


^EXPAND 


reserved keyword 


quote-function 


'^■EXPLODE 


reserved keyword 


delimiter-function 


f ;fFI 


reserved keyword 


lexical-conditional 


'(FIELDEXPAND 


reserved keyword 


fieldexpand-function 


c cG 


reserved keyword 


float-literal 


<oH 


reserved keyword 


float-literal 


^IDENTICAL 


reserved keyword 


sequence-test- function 


f cIF 


reserved keyword 


lexical-conditional 


^INFORM 


reserved keyword 


advisory-function 


( rISSTRING 


reserved keyword 


exp-test-function 


f c LENGTH 


reserved keyword 


macro-function 


f ( LTCE 


reserved keyword 


exp-test-function 


f V MESSAGE 


reserved keyword 


advisory-function 


c fNAME 


reserved keyword 


name-function 


f rNBITS 


reserved keyword 


bits-function 


f rNBITSU 


reserved keyword 


bits-function 


r rNULL 


reserved keyword 


sequence-test-function 


%NUMBER 


reserved keyword 


calculation-function 


( cO 


reserved keyword 


integer-literal 


9rP 


reserved keyword 


string-literal 


SPRINT 


reserved keyword 


advisory-function 


%QUOTE 


reserved keyword 


quote-function 


c rQUOTENAME 


reserved keyword 


macro-name function 


f :rRAD50_10 


reserved keyword(36) 


string-literal 


f rRAD50_ll 


reserved keyword(16,32) 


string-literal 


%REF 


reserved keyword 


standard-function 


^REMAINING 


reserved keyword 


macro-function 


%REMOVE 


reserved keyword 


delimiter-function 


%REQUIRE 


reserved keyword 


require-function 


%SBTTL 


reserved keyword 


title-function 


%SIXBIT 


reserved keyword(36) 


string-literal 


%SIZE 


reserved keyword 


allocation-function 


%STRING 


reserved keyword 


string-function 


%SWITCHES 


reserved keyword 


compiler-state-function 


%THEN 


reserved keyword 


lexical-conditional 


%TITLE 


reserved keyword 


title-function 
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Identifier Classification Usage 

v c UN QUOTE reserved keyword quote-function 

%UPVAL reserved keyword predeclared literal 

% VARIANT reserved keyword compiler-state-function 

^rWARN reserved keyword advisory-function 

c 'f X reserved keyword integer-literal 
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Appendix B 
String Encodings 



This appendix describes the several types of character-string encodings used 
in the BLISS dialects: 

• In BLISS-16 and BLISS-32 — ASCII and RAD50_11 

• In BLISS-36 — ASCII, RAD50_10, and SIXBIT 



B.1 ASCII Encoding 



An ASCII string-literal is a common way of encoding a character sequence. 
The size of an ASCII character position varies with the dialect as follows: In 
BLISS-16 and BLISS-32, one character occupies an 8-bit byte; in BLISS-36, 
each 36-bit word contains five ASCII character positions, each of which occu- 
pies seven bits. 

The code value for each ASCII character can be found in the accompanying 
"ASCII Code Table", both in octal and hexadecimal representation. 



B-l 



ASCII Code Table 



Octal 


Hex 


ASCII 


Octal 


Hex 


ASCII 


Octal 


Hex 


ASCII 


Code 


Code 


Char. 


Code 


Code 


Char. 


Code 


Code 


Char. 


000 


00 


NUL 


053 


2B 


+ 


126 


56 


V 


001 


01 


SOH 


054 


2C 




127 


57 


W 


002 


02 


STX 


055 


2D 


- 


130 


58 


X 


003 


03 


ETX 


056 


2E 




131 


59 


Y 


004 


04 


EOT 


057 


2F 


/ 


132 


5A 


Z 


005 


05 


ENQ 


060 


30 





133 


5B 


[ 


006 


06 


ACK 


061 


31 


1 


134 


5C 


\ 


007 


07 


BEL 


062 


32 


2 


135 


5D 


] 


010 


08 


BS 


063 


33 


3 


136 


5E 


* 


Oil 


09 


HT 


064 


34 


4 


137 


5F 


_ 


012 


0A 


LF 


065 


35 


5 


140 


60 


v 


013 


0B 


VT 


066 


36 


6 


141 


61 


a 


014 


OC 


FF 


067 


37 


7 


142 


62 


b 


015 


OD 


CR 


070 


38 


8 


143 


63 


c 


016 


OE 


SO 


071 


39 


9 


144 


64 


d 


017 


OF 


SI 


072 


3A 




145 


65 


e 


020 


10 


DLE 


073 


3B 


; 


146 


66 


f 


021 


11 


DC1 


074 


3C 


< 


147 


67 


g 


022 


12 


DC2 


075 


3D 


= 


150 


68 


h 


023 


13 


DC3 


076 


3E 


> 


151 


69 


i 


024 


14 


DC4 


077 


3F 


? 


152 


6A 


J 


025 


15 


NAK 


100 


40 


@ 


153 


6B 


k 


026 


16 


SYN 


101 


41 


A 


154 


6C 


1 


027 


17 


ETB 


102 


42 


B 


155 


6D 


m 


030 


18 


CAN 


103 


43 


C 


156 


6E 


n 


031 


19 


EM 


104 


44 


D 


157 


6F 





032 


1A 


SUB 


105 


45 


E 


160 


70 


P 


033 


IB 


ESC 


106 


46 


F 


161 


71 


q 


034 


1C 


FS 


107 


47 


G 


162 


72 


r 


035 


ID 


GS 


110 


48 


H 


163 


73 


s 


036 


IE 


RS 


111 


49 


I 


164 


74 


t 


037 


IF 


US 


112 


4A 


J 


165 


75 


u 


040 


20 


space 


113 


4B 


K 


166 


76 


V 


041 


21 


! 


114 


4C 


L 


167 


77 


w 


042 


22 


ii 


115 


4D 


M 


170 


78 


X 


043 


23 


# 


116 


4E 


N 


171 


79 


y 


044 


24 


$ 


117 


4F 


O 


172 


7A 


z 


045 


25 


% 


120 


50 


P 


173 


7B 


{ 


046 


26 


& 


121 


51 


Q 


174 


7C 


1 


047 


27 


' 


122 


52 


R 


175 


7D 


}_ 


050 


28 


( 


123 


53 


S 


176 


7E 




051 


29 


) 


124 


54 


T 


177 


7F 


DEL 


052 


2A 


* 


125 


55 


U 
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B.2 RADIX-50 Encoding 



A Radix-50 string-literal specifies a particular way of encoding and packing a 
sequence of characters. The characters in the string-literal must be members 
of the Radix-50 character set, which is a 40-character subset of the ASCII 
graphic characters. This subset is the same for all three BLISS dialects, but 
the details of encoding and packing vary between BLISS-16 and BLISS-32 on 
one hand (RAD50_11) and BLISS-36 on the other (RAD50_10). These two 
variations of Radix-50 encoding are described in the following two subsec- 
tions. 

B.2.1 RAD50_11 Encoding 

In BLISS-16 and BLISS-32, Radix-50 encoding is invoked using the 
%RAD50 11 string function (see Section 4.3). A sequence of Radix-50 char- 
acters is packed three characters per 16-bit word, as described below. 

If necessary, trailing blanks are added so that the number of characters in the 
sequence is a multiple of three. Then the sequence is divided into groups of 
three characters. The code for each character is obtained from the accompa- 
nying "RAD50 11 Code Table", based on both the character and its position 

in its group. Then the octal codes for each character in a group are added 
together to obtain a 16-bit value. 

As an example, suppose the string-literal %RAD50 ll'AB' must be evalu- 
ated. First, a trailing blank is added, giving %RAD50_11'AB '. Then the 
literal is encoded and packed as follows: 

A (as first character) = 003100 

B (as second character) = 000120 

Blank (as third character) = 000000 

%RAD50_11'AB ' = 003220 (octal) 

The character encoding table is derived as follows. The Radix-50 character set 
is composed of 50 (octal) characters. These characters are treated as the 
"digits" of a radix-50 number system. Suppose the i'th character of the set 
must be encoded. Depjnding on whether it is the first (leftmost), second, or 
third character of a sequence, the character is encoded as 50*50*i, 50*i, or i 
(all octal). The value 50 (octal) was chosen as the radix because it is the 
largest value that permits the packing of three characters into a 16-bit word. 
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RAD50__11 Code Table 





First 




Second 




Third 


Character 


( 


Character 


Character 


Blank 


000000, 


Blank 


000000 


Blank 


000000 


A 


003100 


A 


000050 


A 


000001 


B 


006200 


B 


000120 


B 


000002 


C 


011300 


C 


000170 


C 


000003 


D 


014400 


D 


000240 


D 


000004 


E 


017500 


E 


000310 


E 


000005 


F 


022600 


F 


000360 


F 


000006 


G 


025700 


G 


000430 


G 


000007 


H 


031000 


H 


000500 


H 


000010 


I 


034100 


I 


000550 


I 


000011 


J 


037200 


J 


000620 


J 


000012 


K 


042300 


K 


000670 


K 


000013 


L 


045400 


L 


000740 


L 


000014 


M 


050500 


M 


001010 


M 


000015 


N 


053600 


N 


001060 


N 


000016 





056700 





001130 





000017 


P 


062000 


P 


001200 


P 


000020 


Q 


065100 


Q 


001250 


Q 


000021 


R 


070200 


R 


001320 


R 


000022 


S 


073300 


S 


001370 


S 


000023 


T 


076400 


T 


001440 


T 


000024 


U 


101500 


U 


001510 


U 


000025 


V 


104600 


V 


001560 


V 


000026 


w 


107700 


W 


001630 


W 


000027 


X 


113000 


X 


001700 


X 


000030 


Y 


116100 


Y 


001750 


Y 


000031 


z 


121200 


Z 


002020 


Z 


000032 


$ 


124300 


$ 


002070 


$ 


000033 




127400 




002140 




000034 


Unused 


132500 


Unused 


002210 


Unused 


000035 





135600 





002260 





000036 


1 


140700 


1 


002330 


1 


000037 


2 


144000 


2 


002400 


2 


000040 


3 


147100 


3 


002450 


3 


000041 


4 


152200 


4 


002520 


4 


000042 


5 


155300 


5 


002570 


5 


000043 


6 


160400 


6 


002640 


6 


000044 


7 


163500 


7 


002710 


7 


000045 


8 


166600 


8 


002760 


8 


000046 


9 


171700 


9 


003030 


9 


000047 
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B.2.2 RAD50_10 Encoding 

In BLISS-36, Radix-50 encoding is invoked using the %RAD50 10 string 

function (see Section 4.3). A sequence of Radix-50 characters are encoded and 
packed six characters per 36-bit word, as described below. 

The sequence is divided into groups of six characters. If the last (or only) 
group contains less than six characters, leading blanks are added to the group 
in order to extend it to six characters. For each of these groups, the code for 

each character is obtained from the accompanying "RAD50 10 Code Table" 

which lists codes starting with the righthand character. (Note that this table 

has several differences from the RAD50 11 table.) Then these octal codes are 

added to obtain a 36-bit value. As an example, suppose the string-literal 

%RAD50 11 'ABCD' must be evaluated. First, two leading blanks are added, 

giving %RAD50-11 ' ABCD'. Then the literal is encoded and packed as 
follows: 

D (as rightmost character) = 000000000016 

C (as second character from right) = 000000001010 

B (as third character from right) = 000000045400 

A (as fourth character from right) = 000002537000 

Blank (as fifth character from right) = 000000000000 

Blank (as sixth character from right) = 000000000000 

%RAD50__10' ABCD' = 000002605426 (octal) 

The RAD50 10 character encoding table is derived as follows. The Radix-50 

character set is composed of 50 (octal) characters. These characters are 
treated as the "digits" of a Radix-50 number system. If the i'th character of 
the set which is located as the n'th character from the right in a group must be 
encoded it is represented as (50**(n-l))*i (where numbers are octal and ** 
denotes exponentiation). Thus if six characters are numbered from right to 
left in the form: 

C(6) C(5) C(4) C(3) C(2) C(l) 

where C(n) is the octal code for the n'th character, the RAD50 10 representa- 
tion of the character string can be generated by: 

(((((( C ( B ) #50 ) +C ( 5 ) ) *50+C ( a ) ) *50+C ( 3 ) ) *50+C ( 2 ) ) *50+C ( 1 ) 

where all numbers are octal. 
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RAD50_10 Code Table 





Rightmost 




Second 




Third 




Character 




Character 




Character 




Code 




From Right 




From Right 


Blank 


: 000000000000 


Blank 000000000000 


Blank 000000000000 





000000000001 





000000000050 





000000003100 


1 


000000000002 


1 


000000000120 


1 


000000006200 


2 


000000000003 


2 


000000000170 


2 


000000011300 


3 


000000000004 


3 


000000000240 


3 


000000014400 


4 


000000000005 


4 


000000000310 


4 


000000017500 


5 


000000000006 


5 


000000000360 


5 


000000022600 


6 


000000000007 


6 


000000000430 


6 


000000025700 


7 


000000000010 


7 


000000000500 


7 


000000031000 


8 


000000000011 


8 


000000000550 


8 


000000034100 


9 


000000000012 


9 


000000000620 


9 


000000037200 


A 


000000000013 


A 


000000000670 


A 


000000042300 


B 


000000000014 


B 


000000000740 


B 


000000045400 


C 


000000000015 


C 


000000001010 


C 


000000050500 


D 


000000000016 


D 


000000001060 


D 


000000053600 


E 


000000000017 


E 


000000001130 


E 


000000056700 


F 


000000000020 


F 


000000001200 


F 


000000062000 


G 


000000000021 


G 


000000001250 


G 


000000065100 


H 


000000000022 


H 


000000001320 


H 


000000070200 


I 


000000000023 


I 


000000001370 


I 


000000073300 


J 


000000000024 


J 


000000001440 


J 


000000076400 


K 


000000000025 


K 


000000001510 


K 


000000101500 


L 


000000000026 


L 


000000001560 


L 


000000104600 


M 


000000000027 


M 


000000001630 


M 


000000107700 


N 


000000000030 


N 


000000001700 


N 


000000113000 





000000000031 





000000001750 


O 


000000116100 


P 


000000000032 


P 


000000002020 


P 


000000121200 


Q 


000000000033 


Q 


000000002070 


Q 


000000124300 


R 


000000000034 


R 


000000002140 


R 


000000127400 


S 


000000000035 


S 


000000002210 


S 


000000132500 


T 


000000000036 


T 


000000002260 


T 


000000135600 


U 


000000000037 


U 


000000002330 


U 


000000140700 


V 


000000000040 


V 


000000002400 


V 


000000144000 


W 


000000000041 


w 


000000002450 


W 


000000147100 


X 


000000000042 


, x 


000000002520 


X 


000000152200 


Y 


000000000043 


Y 


000000002570 


Y 


000000155300 


Z 


000000000044 


z 


000000002640 


Z 


000000160400 




000000000045 




000000002710 




000000163500 


$ 


000000000046 


$ 


000000002760 


$ 


000000166600 


% 


000000000047 


% 


000000003030 


% 


000000171700 
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RAD50_10 Code Table 





Fourth 




Fifth 




Sixth 




Character 




Character 




Character 




From Right 




From Right 




From Right 


Blank 


; 000000000000 


Blank 


: 000000000000 


Blank 


: 000000000000 





000000175000 





000011610000 





000606500000 


1 


000000372000 


1 


000023420000 


1 


001415200000 


2 


000000567000 


2 


000035230000 


2 


002223700000 


3 


000000764000 


3 


000047040000 


3 


003032400000 


4 


000001161000 


4 


000060650000 


4 


003641100000 


5 


000001356000 


5 


000072460000 


5 


004447600000 


6 


000001553000 


6 


000104270000 


6 


005256300000 


7 


000001750000 


7 


000116100000 


7 


006065000000 


8 


000002145000 


8 


000127710000 


8 


006673500000 


9 


000002342000 


9 


000141520000 


9 


007502200000 


A 


000002537000 


A 


000153330000 


A 


010310700000 


B 


000002734000 


B 


000165140000 


B 


011117400000 


C 


000003131000 


C 


000176750000 


C 


011726100000 


D 


000003326000 


D 


000210560000 


D 


012534600000 


E 


000003523000 


E 


000222370000 


E 


013343300000 


F 


000003720000 


F 


000234200000 


F 


014152000000 


G 


000004115000 


G 


000246010000 


G 


014760500000 


H 


000004312000 


H 


000257620000 


H 


015567200000 


I 


000004507000 


I 


000271430000 


I 


016375700000 


J 


000004704000 


J 


000303240000 


J 


017204400000 


K 


000005101000 


K 


000315050000 


K 


020013100000 


L 


000005276000 


L 


000326660000 


L 


020621600000 


M 


000005473000 


M 


000340470000 


M 


021430300000 


N 


000005670000 


N 


000352300000 


N 


022237000000 





000006065000 





000364110000 





023045500000 


P 


000006262000 


P 


000375720000 


P 


023654200000 


Q 


000006457000 


Q 


000407530000 


Q 


024462700000 


R 


000006654000 


R 


000421340000 


R 


025271400000 


S 


000007051000 


S 


000433150000 


S 


026100100000 


T 


000007246000 


T 


000444760000 


T 


026706600000 


U 


000007443000 


U 


000456570000 


U 


027515300000 


V 


000007640000 


V 


000470400000 


V 


030324000000 


w 


000010035000 


W 


000502210000 


W 


031132500000 


X 


000010232000 


X 


000514020000 


X 


031741200000 


Y 


000010427000 


Y 


000525630000 


Y 


032547700000 


z 


000010624000 


Z 


000537440000 


Z 


033356400000 




000011021000 




000551250000 




034165100000 


$ 


000011216000 


$ 


000563060000 


$ 


034773600000 


% 


000011413000 


% 


000574670000 


% 


035602300000 
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B.3 SIXBIT Encoding 



In BLISS-36, SIXBIT encoding is invoked using the %SIXBIT string function 
(see Section 4.3). SIXBIT encoding applies to the 64-character graphic subset 
of the ASCII characters. A sequence of SIXBIT characters are encoded as 
follows. 

A character-sequence is divided into groups of six characters, with trailing 
blanks added to fill the final (or only) group of six, if necessary. Lowercase 
letters are converted to uppercase and then the 6-bit character code found in 
the accompanying "SIXBIT Code Table" is obtained for each character. 
These six 6-bit codes form a fullword (36-bits). 

SIXBIT Code Table 



Octal 


SIXBIT 


Octal 


SIXBIT 


Octal 


SIXBIT 


Code 


Char 


Code 


Char 


Code 


Char 


00 


space 


25 


5 


53 


K 


01 


t 


26 


6 


54 


L 


02 


H 


27 


7 


55 


M 


03 


# 


30 


8 


56 


N 


04 


$ 


31 


9 


57 


O 


05 


% 


32 




60 


P 


06 


& 


33 


; 


61 


Q 


07 


' 


34 


< 


62 


R 


10 


( 


35 


= 


63 


S 


11 


) 


36 


> 


64 


T 


12 


* 


37 


? 


65 


U 


13 


+ 


40 


@ 


66 


V 


14 


, 


41 


A 


67 


W 


15 


- 


42 


B 


70 


X 


16 




43 


C 


71 


Y 


17 


/ 


44 


D 


72 


Z 


20 





45 


E 


73 


[ 


21 


1 


46 


F 


74 


\ 


22 


2 


47 


G 


75 


] 


23 


3 


50 


I 


76 


* 


24 


4 


51 


J 


77 




25 


5 


52 


K 
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Appendix C 
Transportability Checking 



This appendix describes the transportability checking that is performed by 
each compiler in response to the LANGUAGE special-switch. See Sections 
18.2 and 19.2 for the description of the LANGUAGE switch, and particularly 
Section 18.2.5 for a general discussion of its use. 

When transportability checking is performed, the compiler scans the source 
input for any of the language features described below, and issues a warning 
message reporting any occurrence of such features. Two classes of transporta- 
bility checking are currently provided, depending on how the language-list is 
specified in the LANGUAGE switch. The two classes are: 

1. Full Transportability Checking — Performed if any one of the specifica- 
tions 

COMMON 
BLISS16,BLISS36 
BLISS32,BLISS36 
BLISS16,BLISS32,BLISS36 

appears in the language-list. All dialectal constructs are checked for, as 
well as any other construct likely to cause problems in transporting a 
program between any two target systems. 

2. BLISS-16/BLISS-32 Subset Checking — Performed if the specification 

BLISS16,BLISS32 

appears in the language list. Essentially this is a somewhat relaxed form 
of full (i.e., Common BLISS) checking. Certain dialectal features that 
are valid in both BLISS-16 and BLISS-32 are not checked for in this 
case. 

When no LANGUAGE switch appears in the module-head, or when a switch 
that specifies or implies only one language-name appears in either the mod- 
ule-head or a SWITCHES declaration, no transportability checking is done 
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within the module or within the scope of the declaration, respectively. (Ex- 
cept that the switch specification, if explicit, is checked for validity.) If speci- 
fied, the LANGUAGE switch must include (or imply) the language-name 
corresponding to the compiler in use. 

The specific language constructs involved in full checking and in 
BLISS- 16/BLISS-32 subset checking are described in separate sections be- 
low. 

C.1 Full Transportability Checking 

The dialectal or problematic language features checked for and reported on 
under full checking are categorized below in alphabetical order. 

Attributes — The dialectal attributes are: 

• Addressing- mode attribute 

• Alignment-attribute 

• Allocation-units BYTE, WORD, and LONG 

• Extension-attributes SIGNED and UNSIGNED (when used as exten- 
sion-attributes, see note below) 

• Weak-attribute 

NOTE: The keyword SIGNED or UNSIGNED when used as part of a range- 
attribute in a literal-declaration is a Common BLISS construct. 

Builtin Names and Declarations — The occurrence, in a BUILTIN declara- 
tion, of any builtin-name except ACTUALCOUNT or ACTUAL- PARAME- 
TER (common linkage-functions) is reported. 

Condition Handling Features — Any use of an ENABLE declaration or SIG- 
NAL expression is reported. 

Field Selectors — Any field-selector that specifies a field not entirely con- 
tained within a fullword is reported. (That is, the position and size values 
must not exceed %BPVAL, and neither must their sum.) Also, any field- 
reference that does not modify a fetch or store operation and whose position 
value is not zero is reported. Note that the field-selector parameters must be 
compile-time-constant-expressions in order for the compiler to perform this 
checking. 

GLOBAL and EXTERNAL Names — The occurrence of any global- or ex- 
ternal-name that is not unique (throughout the module) within its first six 
characters is reported. 

Linkage Declarations — Any use of a linkage-declaration is reported. 

Linkage Switches and Linkage Attributes — The use of any linkage-name 
other than FORTRAN_FUNC or FORTRAN__SUB in a linkage-switch or 
linkage- attribute is reported. 
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Literals — Occurrences of the following kinds of literals are reported: 

• %E, %D, %G, and %H numeric-literals (floating point) and %P string- 
literals (packed decimal) 

• Any string-literal used as a primary expression (i.e., not a plit-item) 

• An "alphanumeric" string-literal with a string-type other than %ASCII or 

%ASCIZ. 

PSECT Declarations — Any use of a PSECT declaration is reported. 

Switches — The occurrences of any of the following module-switches is re- 
ported: 

ADDRESSING_MODE OTS OTS_LINKAGE 

C.2 BLISS-16/BLISS-32 Subset Checking 

The slightly less restrictive set of language features (relative to full checking) 
checked for and reported on under BLISS-16/BLISS-32 subset checking is 
categorized below in alphabetical order. 

(Briefly, the allocation-units BYTE and WORD, the extension-units SIGNED 
and UNSIGNED, and the string-type %RAD50 11 are considered transport- 
able constructs in this case.) 

Attributes — The attributes checked on are: 

• Addressing-mode attribute 

• Alignment-attribute 

• Allocation-unit LONG 

• Weak-attribute 

Builtin Names and Declarations — The occurrence, in a BUILTIN declara- 
tion, of any builtin-name except ACTUALCOUNT or ACTUAL-PARAME- 
TER (common linkage-functions) is reported. 

Condition Handling Features — Any use of an ENABLE declaration or SIG- 
NAL expression is reported. 

Field Selectors — Any field-selector that specifies a field not entirely con- 
tained within a fullword is reported. (That is, the position and size values 
must not exceed %BPVAL, and neither must their sum.) Also, any field- 
reference that does not modify a fetch or store operation and whose position 
value is not zero is reported. Note that the field-selector parameters must be 
compile-time-constant-expressions in order for the compiler to perform this 
checking. 

GLOBAL and EXTERNAL Names — The occurrence of any global- or ex- 
ternal-name that is not unique (throughout the module) within its first six 
characters is reported. 

Linkage Declarations — Any use of a linkage-declaration is reported. 
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Linkage Switches and Linkage Attributes — The use of any linkage-name 
other than FORTRAN_FUNC or FORTRAN_SUB in a linkage-switch or 
linkage-attribute is reported. 

Literals — Occurrences of the following kinds of literals are reported: 

• %E, %D, %G, and %H numeric-literals (floating point) and %P string- 
literals (packed decimal) 

• Any string-literal used as a primary expression (i.e., not a plit-item) 

• An "alphanumeric" string-literal with a string-type other than %ASCII, 
%ASCIZ, or %RAD50_11. 

PSECT Declarations — Any use of a PSECT declaration is reported. 

Switches — The occurrences of any of the following module-switches is re- 
ported: 

ADDRESSING_MODE OTS OTS_LINKAGE 
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D.l BLISS-16 Machine Specific Functions D-l 

D.l.l Memory Management Operations D-l 

D.l. 2 Processor Status Operations D-l 

D.l. 3 Bit Manipulation Operations D-l 

D.l. 4 Arithmetic Operations D-l 

D.l. 5 Arithmetic Comparison Operations D-2 

D.l. 6 Arithmetic Conversion Operations D-2 

D.l. 7 Processor Action Operations D-2 

D.1.8 Miscellaneous Operations D-2 
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Appendix D 
Builtin Functions 



This appendix lists the names of the builtin machine-specific-functions prede- 
fined for each BLISS dialect. Detailed descriptions of these functions may be 
found in the user's guide associated with each BLISS dialect. 

D.1 BLISS-16 Machine Specific Functions 

D.1.1 Memory Management Operations 

MFPD Move from previous data space 

MTPD Move to previous data space 

MFPI Move from previous instruction space 

MTPI Move to previous instruction space 

D.1 .2 Processor Status Operations 

MFPS Move byte from processor status word 

MTPS Move byte to processor status word 

SPL Set priority level 

D.1 .3 Bit Manipulation Operations 

ROT Rotate 

SWAB Swap bytes 

D.1 .4 Arithmetic Operations 

ADDD Add double operands 

ADDF Add float operands 

ADDM Add multiword operands 

DIVD Divide double operands 

DIVF Divide float operands 
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EDIV Extended-precision divide 

EMUL Extended-precision multiply 

MULD Multiply double operands 

MULF Multiply float operands 

SUBD Subtract double operands 

SUBF Subtract float operands 

SUBM Subtract multiword operands 

D.1.5 Arithmetic Comparison Operations 

CMPD Compare double operands 

CMPF Compare float operands 

CMPM Compare multiword operands 

D.1.6 Arithmetic Conversion Operations 

CVTDF Convert double to float 

CVTFD Convert float to double 

CVTDI Convert double to integer 

CVTID Convert integer to double 

CVTFI Convert float to integer 

CVTIF Convert integer to float 

D.1.7 Processor Action Operations 

BPT Breakpoint trap 

HALT Halt processor 

NOP No operation 

RESET Reset hardware 

WAIT Processor wait 

D.1.8 Miscellaneous Operations 

DECX Specialized routine call 

D.2 BLISS-32 Machine Specific Functions 

D.2.1 Processor Register Operations 

MFPR Move from a processor register 

MTPR Move to a processor register 

D.2. 2 Parameter Validation Operations 

PROBER Probe read accessibility 

PROBEW Probe write accessibility 
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D.2.3 Program Status Operations 



BICPSW 
BISPSW 

MOVEPSL 



Bit clear processor status word 
Bit set processor status word 

Move from processor status longword 



D.2.4 Queue Operations 



INSQHI 
REMQHI 

INSQTI 
REMQTI 



Insert entry in queue head, interlocked 
Remove entry from queue head, interlocked 

Insert entry in queue tail, interlocked 
Remove entry from queue tail, interlocked 



D.2.5 Bit Operations 



FFC 
FFS 

TESTBITCC 
TESTBITCS 

TESTBITSC 
TESTBITSS 

TESTBITCCI 
TESTBITSSI 



Find first clear bit 
Find first set bit 

Test for bit clear, then clear bit 
Test for bit clear, then set bit 

Test for bit set, then clear bit 
Test for bit set, then set bit 

Test for bit clear, then clear bit interlocked 
Test for bit set, then set bit interlocked 
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ADAWI 

ADDD 
ADDF 
ADDG 
ADDH 
ADDM 

ASHQ 

DIVD 
DIVF 
DIVG 
DIVH 

EDIV 
EMUL 

MULD 
MULF 
MULG 
MULH 

SUBD 
SUBF 



Add aligned word interlocked 

Add double operands 
Add float operands 
Add float-G operands 
Add float-H operands 
Add multiword operands 

Arithmetic shift quad 

Divide double operands 
Divide float operands 
Divide float-G operands 
Divide float-H operands 

Extended-precision divide 
Extended-precision multiply 

Multiply double operands 
Multiply float operands 
Multiply float-G operands 
Multiply float-H operands 

Subtract double operands 
Subtract float operands 
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SUBG 


Subtract float-G operands 


SUBH 


Subtract float-H operands 


SUBM 


Subtract multiword operands 


D.2.7 Arithmetic Comparison Operations 


CMPD 


Compare double operands 


CMPF 


Compare float operands 


CMPG 


Compare float-G operands 


CMPH 


Compare float-H operands 


CMPM 


Compare multiword operands 


D.2.8 Arithmetic Conversion Operations 


CVTDF 


Convert double to float 


CVTFD 


Convert float to double 


CVTDI 


Convert double to integer 


CVTID 


Convert integer to double 


CVTDL 


Convert double to long 


CVTLD 


Convert long to double 


CVTFG 


Convert float to float-G 


CVTGF 


Convert float-G to float 


CVTFH 


Convert float to float-H 


CVTHF 


Convert float-H to float 


CVTFI 


Convert float to integer 


CVTIF 


Convert integer to float 


CVTFL 


Convert float to long 


CVTLF 


Convert long to float 


CVTLG 


Convert long to float-G 


CVTGL 


Convert float-G to long 


CVTLH 


Convert long to float-H 


CVTHL 


Convert float-H to long 


CVTRDH 


Convert rounded double to float-H 


CVTRDL 


Convert rounded double to long 


CVTRFL 


Convert rounded float to long 


CVTRGH 


Convert rounded float-G to float-H 


CVTRGL 


Convert rounded float-G to long 


CVTRHL 


Convert rounded float-H to long 


D.2.9 Character 


String Operations 


CMPC3 


Compare characters 3 operand 


CMPC5 


Compare characters 5 operand 



CRC 



Calculate cyclic redundancy check 
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LOCC 
SKPC 

MOVC3 
MOVC5 
MOVTC 
MOVTUC 

MATCHC 

SCANC 
SPANC 



Locate character 
Skip character 

Move character 3 operand 
Move character 5 operand 
Move translated characters 
Move translated until character 

Match characters 
Scan characters 
Span characters 



D.2.10 Decimal String Operations 



ASHP 

CMPP 

CVTLP 
CVTPL 

CVTPS 
CVTSP 

CVTPT 
CVTTP 

EDITPC 

MOVP 



Arithmetic shift and round packed 

Compare packed 

Convert long to packed 
Convert packed to long 

Convert packed to leading separate numeric 
Convert leading separate numeric to packed 

Convert packed to trailing numeric 
Convert trailing numeric to packed 

Edit packed to character string 

Move packed 



D.2.11 Processor Action Operations 

BPT Breakpoint 

CHM(x) Change mode 

HALT Halt processor 

NOP No operation 

D.2.12 Miscellaneous Operations 



BUGL 
BUGW 


Bugcheck with long operand 
Bugcheck with word operand 


CALLG 


Call with general argument list 


INDEX 


Compute index 


ROT 


Rotate 


XFC 


Extended function call 
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D.3 BLISS-36 Machine Specific Functions 

D.3.1 Logical Operations 

ASH Arithmetically shift a value 

FIRSTONE Find the leftmost non-zero list in a value 

LSH Logically shift a value 

ROT Rotate a value 



D.3. 2 Byte Manipulation Operations 


COPYII 


Increment both source and destination byte 
pointers and copy a byte 


COPYIN 


Increment a source byte pointer and copy a 
byte 


COPTNI 


Increment a destination byte pointer and copy 
a byte 


COPYNN 


Copy a byte 


DPB 


Deposit a byte 


INCP 


Increment a byte pointer 


LDB 


Load a byte 


POINT 


Build a DEC-10/-20 byte pointer 


REPLACEI 


Increment a byte pointer and store a byte 


REPLACEN 


Store a byte given a byte pointer 


SCANI 


Increment a byte pointer and fetch a byte 


SCANN 


Fetch a byte given a byte pointer 


D.3. 3 Arithmetic Operations 


ADDD 
ADDF 
ADDG 


Add double operands 
Add float operands 
Add float-G operands 


DIVD 
DIVF 
DIVG 


Divide double operands 
Divide float operands 
Divide float-G operands 


MULD 
MULF 
MULG 


Multiply double operands 
Multiply float operands 
Multiply float-G operands 


SUBD 
SUBF 
SUBG 


Subtract double operands 
Subtract float operands 
Subtract float-G operands 
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D.3.4 Arithmetic Comparison Operations 



CMPD 


Compare double operands 


CMPF 


Compare float operands 


CMPG 


Compare float-G operands 


D.3.5 Arithmetic Conversion Operations 


CVTDF 


Convert double to float 


CVTFD 


Convert float to double 


CVTDI 


Convert double to integer 


CVTID 


Convert integer to double 


CVTFI 


Convert float to integer 


CVTIF 


Convert integer to float 


CVTGF 


Convert float-G to float 


CVTFG 


Convert float to float-G 


CVTGI 


Convert float-G to integer 


CVTIG 


Convert integer to float-G 



D.3.6 Machine Code insertion Operations 

MACHOP Execute a DEC-10/-20 instruction 

MACHSKIP Execute a DEC-10/-20 instruction and record any 

skip 

D.3.7 System Interface Operations 

JSYS Perform a TOPS-20 monitor call 

UUO Perform a TOPS-10 monitor call 
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An asterisk (*) indicates the syntax description for the entry. 



ABS standard function, 5-15 
ABSOLUTE 

in addressing-mode-attribute, 9-17 

in module-switch(16), 19-5 

in module-switch(32), 19-6 

in switch, 18-12 
Access-actual* 

in default-structure-reference, 
11-31 

in general-structure-reference, 
11-35 

in ordinary-structure-reference, 
11-29 

in preset-attribute, 9-10 
Access-formal*, 11-22 
ACTUALCOUNT linkage-function, 13-29 
ACTU ALP ARAMETER linkage-function, 

13-29 
ADAWK32), D-3 
ADDD(16,32,36), D-l 
ADDF(16,32,36), D-l 
ADDG(32,36), D-3 
ADDH(32), D-3 
Addition operator, 5-8 
ADDM( 16,32), D-l 
Address offset 

in alignment-attribute, 9-6 
Address* 

in default-structure-reference, 
11-31 

in field-reference, 11-12 
Address, encoded, 9-18 
Addressable unit, 3-6 

usage of, 1-5 
Addressing 

dialectal differences in, 1-5 

introduction to, 1-5 



Addressing- mode-attribute*, 9-17 

as psect-attribute, 18-3 

in external-routine-decl, 12-17 

in forward-routine-decl, 12-16 
ADDRESSING—MODE 

in attribute, 9-17 

in module-switch(16), 19-5 

in module-switch(32), 19-6 

in module-switch(36), 19-6 

in switch, 18-11 
Alignment-attribute*, 9-6 

as psect-attribute, 18-3 
%ALLOCATION function, 15-33 
Allocation functions 

for character handling, 20-3 
Allocation-actual* 

in general-structure-reference, 
11-35 

in structure-attribute, 11-24 
Allocation-default*, 11-22 
Allocation-formal*, 11-22 
Allocation-unit* 

as attribute, 9-2 

in general-structure-reference, 
11-35 

in plit, 4-13 

in structure-attribute, 11-24 
Alternative*, 6-2 

ALWAYS in select-expression, 6-£ 
AND as infix operator, 5-9 
Apostrophe 

in character-code-literal, 4-4 

in float-literal, 4-4 

in integer-literal, 4-3 

in string-literal, 4-8 
ARGPTR linkage-function, 13-29 
Argument (see Parameter) 
Argument block, 13-7 
Argument passing, 12-11 
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Argument pointer (AP) register, 13-3, 

13-7 
Arithmetic comparison operations 
builtin 
double(16,32,36), D-2, D-4, D-7 
float(16,32,36), D-2, D-4, D-7 
float-G(32,36), D-4, D-7 
float-H(32), D-4 
multiword(16,32), D-2, D-4 
infix 
address, 5-8 
signed integer, 5-8 
unsigned integer, 5-8 
Arithmetic conversion operations 
builtin(16,32,36), D-2, D-4, D-7 
Arithmetic expression, 5-7 
Arithmetic operations 
builtin 
double(16,32,36), D-l, D-3, D-6 
float(16,32,36), D-l, D-3, D-6 
float-G(32,36), D-3, D-6 
float-H(32), D-3 
multiword(16,32), D-l, D-3 
signed integer, 5-7 
Arithmetic shift operations 
ASH(36), D-6 
packed(32), D-5 
quad(32), D-3 
signed, 5-6 
Array 

(see VECTOR structure), 11-38 
%ASCIC in string-literal, 4-8 
ASCIC literal (see %ASCIC) 
%ASCID in string-literal, 4-8 
ASCII 
literal (see %ASCII) 
code table, B-2 
encoding, B-l 
%ASCII in string-literal, 4-8 
%ASCIZ in string-literal, 4-8 
ASCIZ literal (see %ASCIZ) 
ASH(36), D-6 
ASHP(32), D-5 
ASHQ(32), D-3 
ASSEMBLY 
in module-switch, 19-5 
in switch, 18-11 
%ASSIGN function, 15-36 
Assignment expression, 5-10 

introduction to, 1-6 
Associativity, 5-2 
Asterisk as operator, 5-7 



Attribute*, 9-1 
for formal-name, 12-13 
in a declaration, 8-6 
introduction to, 1-9 
summary of usage, 9-20 
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%B in integer-literal, 4-3 
BEGIN in block, 8-2 
BEGIN-END block (see Block) 
BICPSW(32), D-3 
BINARY 

in module-switch, 19-5 

in switch, 18-11 
Binary operators, 5-2 
Bind-data-declaration*, 14-5 
Bind-routine-declaration*, 14-7 
Binding 

in constant expressions, 1-16 

in lexical processing, 15-3 

introduction to, 1-12 
BISPSW(32), D-3 
Bit manipulation operations 

builtin(16,32), D-l, D-3 
Bit operations, 5-9 
Bit-count* 

in range-attribute, 9-16 
Bit-position numbering, 11-16, 11-17 
bit-position numbering, 3-10 
Bits per value, 14-3 
BITVECTOR structure, 11-39 

example of, 3-10 

Blank character, 4-8 
%BLISS function, 15-38 
BLISS System, 1-14 
BLISS value, 3-2 
BLISS10C 

in module-switch(36), 19-6 
BLISS16 

in module-switch, 19-5 

in switch, 18-11 
%BLISS16 macro name, 16-11 
BLISS32 

in module-switch, 19-5 

in switch, 18-11 
%BLISS32 macro name, 16-11 
BLISS36 

in module-switch, 19-5 

in switch, 18-11 
%BLISS36 macro name, 16-11 
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BLISS36C_OTS 

in module-switch(36), 19-6 
BLOCK structure, 11-40 

example of, 3-10 

macros for, 16-24 
Block*, 8-2 

as primary, 4-17 

example of, 8-3 

introduction to, 1-7 

purpose of, 8-1 
BLOCK VECTOR structure, 11-45 

example of, 3-11 
Boolean expression, 5-9 
Bound-declaration*, 14-1 
Boundary* 

in alignment-attribute, 9-6 
Bounds-checking structure, 11-46 
%BPADDR literal-name, 14-3 
BPT(16,32), D-2 
%BPUNIT literal-name, 14-3 
%BPVAL literal-name, 14-3 
Brace character 

in syntax rules, 2-7 
Bracket 

as default punctuation, 16-23 

in macro-actual-parameter, 16-14 

in macro-call, 16-13 

in macro-declaration, 16-8, 16-9 
BUGL(32), D-5 
BUGW(32), D-5 
Builtin names 

machine-specific-functions, D-l 

predefined identifiers, A-l 
Builtin-declaration*, 18-17 
BY in loop-expression, 6-10 
BYTE allocation-unit, 9-2 
Byte manipulation operations 

builtin(36), D-6 
Byte pointer, 3-16, D-6 



%C in character-code-literal, 4-4 
CALL linkage-type(16,32), 13-5, 13-10, 

13-12, 13-15, 13-17 
CALLG(32), D-5 
Calling sequence 

control over, 13-2 

VAX-11 standard, 13-16 
Carriage return character, 2-2 
Case (of letters), 4-16 
Case analysis, 6-4 



Case-expression*, 6-5 

introduction to, 1-11 
Case-label* 

in case-expression, 6-5 
Case-line* 

in case-expression, 6-5 
CH$A_RCHAR function, 20-8 
CH$A_WCHAR function, 20-9 
CH$ALLOCATION function, 20-4 
CH$COMPARE function, 20-12 
CH$COPY function, 20-10 
CH$DIFF function, 20-6 
CH$EQL function, 20-12 
CH$FAIL function, 20-15 
CH$FILL function, 20-10 
CH$FIND_CH function, 20-14 
CH$FIND_NOT_CH function, 20-14 
CH$FIND_SUB function, 20-14 
CH$GEQ function, 20-12 
CH$GTR function, 20-12 
CH$LEQ function, 20-12 
CH$LSS function, 20-12 
CH$MOVE function, 20-9 
CH$NEQ function, 20-12 
CH$PLUS function, 20-6 
CH$PTR function, 20-5 
CH$RCHAR function, 20-8 
CH$RCHAR__A function, 20-8 
CH$SEQUENCE macro, 20-5 
CH$SIZE function, 20-4 
CH$TRANSLATE function, 20-16 
CH$TRANSTABLE function, 20-16 
CH$WCHAR function, 20-8 
CH$WCHAR^_A function, 20-9 
%CHAR function, 15-23 
Character, 2-2 
Character data, 20-2 

representations of, 3-12 
Character handling, 20-1 

functions, 20-3 

operations, 20-2 

character pointer 

description, 3-13 

representation, 3-15, 3-16 
Character sequence 

excessively-long, 15-16 

internal-only, 15-15 
Character string operations 

builtin(32), D-4 
Character-code-literal*, 4-4 
Character-reading functions, 20-7 
Character-writing functions, 20-8 
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^CHARCOUNT function, 15-23 

CHMx(32), D-5 

CLEARSTACK linkage-option, 13-10, 

13-12, 13-22 
CMPC3(32), D-4 
CMPC5(32), D-4 
CMPD(16,32,36), D-2 
CMPF(16,32,36), D-2 
CMPG(32,36), D-4 
CMPH(32), D-4 
CMPM(16,32), D-2 
CMPP(32), D-5 
CODE 

in module-switch, 19-4 

in psect-declaration, 18-3 
$CODE$ default psect, 18-5 
CODECOMMENT*, 4-18 
Colon 

in labeled-block, 8-2 
Comma 

in macro-actual-parameter, 16-14 
Comment, 2-4 
COMMENTARY 

in module-switch, 19-5 

in switch, 18-11 
COMMON 

in module-switch, 19-5 

in switch, 18-11 
Comparing character sequences, 20-12 
Comparison operator 

(see arithmetic comparison 
operations), 5-8 
Compilation 

introduction to, 1-15 

of library source file, 16-28 

role of, 1-4 
Compile-time-constant-expression* 

definition of, 7-3 

discussion of, 7-4 

introduction to, 1-16 

motivation for, 7-1 
Compiletime-declaration*, 15-50 

use with %ASSIGN, 15-36 
Compound-expression, 8-2 

introduction to, 1-8 
Computational expressions, 5-1 
Computed routine addresses, 12-13 
CONCATENATE 

psect-attribute, 18-3 
Concatenation 

in syntax notation, 2-6 
Condition handling, 17-1 

examples of, 17-19 

flow of control, 6-1 



Condition handling, (Cont.) 

flow of control in, 17-12 
examples of, 17-14 

function 
SETUNWIND, 17-11 
SIGNAL, 17-5 
SIGNAL_STOP, 17-6 

in VAX/VMS, 17-29 

introduction to, 17-1 
Condition value, 17-5 

as SIGNAL parameter, 17-5 

as SIGNAL—STOP parameter, 17-6 

comparison of, 17-23, 17-25 

declarations for, 17-22, 17-24 

element of signal vector, 17-9 

structure of, 17-19 
Conditional compilation, 15-49 
Conditional flow of control, 6-1 
Conditional-expression*, 6-2 

introduction to, 1-10 
Conditional-macro-call, 16-13 

expansion of, 16-16 
Conditional-macro-definition*, 16-8 
Consequence*, 6-2 
constant 

character, 4-3 

floating-point, 4-3 

integer, 4-3 

string, 4-7, 4-13 
Constant-expression 

compile-time, 7-3 

introduction to, 1-15 

link-time, 7-5 
Continuation 

in condition handling, 17-10 
Control -expression*, 6-1 
COPTNI(36), D-6 
COPYII(36), D-6 
COPYIN(36), D-6 
COPYNN(36), D-6 
%COUNT function, 15-46 

in conditional-macro expansion, 
16-17 

in iterative- macro expansion, 16-18 

in simple-macro expansion, 16-16 
Counted plit, 4-12 
Counted vector 

definition of, 17-8 
CRC(32), D-4 
%CTCE function, 15-30 
CVTDF(16,32,36), D-2 
CVTDI(16,32,36), D-2 
CVTDL(32), D-4 
CVTFD( 16,32,36), D-2 
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CVTFG(32,36), D-4 
CVTFH(32), D-4 
CVTFI(16,32,36), D-2 
CVTFI(32,36), D-4 
CVTFL(32), D-4 
CVTGF(32,36), D-4 
CVTGL(32), D-4 
CVTHF(32), D-4 
CVTHL(32), D-4 
CVTID(16,32,36), D-2 
CVTIF(16,32,36), D-2 
CVTIF(32,36), D-4 
CVTLD(32), D-4 
CVTLF(32), D-4 
CVTLG(32), D-4 
CVTLH(32), D-4 
CVTLP(32), D-5 
CVTPL(32), D-5 
CVTPS(32), D-5 
CVTPT(32), D-5 
CVTRDH(32), D-4 
CVTRDL(32), D-4 
CVTRFL(32), D-4 
CVTRGH(32), D-4 
CVTRGL(32), D-4 
CVTRHL(32), D-4 
CVTSP(32), D-5 
CVTTP(32), D-5 



%D in float-literal, 4-4 
Dangling ELSE, 6-4 
Data segments 

introduction to, 3-5 
Data structures, 11-1 

(see also Structure) 

abstract definition of, 11-2 

concrete representation of, 11-3 

introduction to, 1-10 

predeclared, 11-38 

programmed description of, 
11-5 

user-defined, 11-46 
Data values 

representation of, 3-1 
Data, introduction to, 1-4 
Data-declaration*, 10-2 
DEBUG 

in module-switch, 19-4 
%DECIMAL in integer-literal, 

4-3 
Decimal string literal 

(see also %P), 4-9 



Decimal string operations 

builtin(32), D-5 

literal, 4-9 
Decimal-digit*, 4-3 
Decimal-literal*, 4-3 
Declaration*, 8-5 

examples of, 8-6 

governs name, 8-5 

introduction to, 1-9 

of loop-index, 6-12 

scope of, 8-5 
%DECLARED function, 15-37 
DECR in loop-expression, 6-10 
DECRA in loop-expression, 6-10 
DECRU in loop-expression, 6-10 
DECX(16), D-2 
Default punctuation 

examples of, 16-22 

in iterative-macro expansion, 16-18 
Default-structure-reference*, 11-31 

compared to ordinary-str-ref, 11-32 

examples of, 11-29, 11-33, 11-52 
Delimiter 

as character, 2-2 

as lexeme, 2-3 
Descriptor 

%ASCID, 4-10 
Design objectives of BLISS, 1-2 
Dialectal distinctions 

in syntax rules, 2-8 
Dialects of BLISS 

introduction to, 1-1 
Direct recursion, 12-7 
Discarded value, 6-4 
Disjunction 

in syntax notation, 2-7 
Displacement, 9-18 
DIVD(16,32,36), D-l 
DIVF(16,32,36), D-l 
DIVG(32,36), D-3 
DIVH(32), D-3 
Division operator, 5-7 
DO in loop-expression, 6-10, 6-13 

double-precision 

float-literal, 4-3 
DPB(36), D-6 



%E in float-literal, 4-4 
EDITPC(32), D-5 
EDIV(16,32), D-2 
EIS 
in module-switch(16), 19-5 
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Ellipsis 

in syntax notation, 2-7 
ELSE in conditional-expression, 6-2 
%ELSE in lexical-conditional, 15-49 
ELUDOM in module, 19-2 
Embedded comment, 2-4 
Empty block 

restriction of, 8-2 
EMT linkage-type(16), 13-10, 13-14 
EMUL(16,32), D-2 
Enable vector, 17-9 

in VAX/VMS, 17-30 
Enable-actual*, 17-3 
Enable-declaration*, 17-3 

examples of, 17-3, 17-28 
Encoded address, 9-18 
Encoding-type, 9-18 
END in block, 8-2 
ENTRY 

in module-switch(36), 19-6 
ENVIRONMENT 

in module-switch(16), 19-5 

in module-switch(36), 19-6 
EQL as infix operator, 5-8 
EQLA as infix operator, 5-8 
EQLU as infix operator, 5-8 
Equals 

as infix operator, 5-10 

in keyword-assignment, 16-13 

in macro-declaration, 16-8, 16-9 
EQV as infix operator, 5-9 
%ERROR function, 15-39 
%ERRORMACRO function, 15-40 
ERRS 

in module-switch, 19-4 

in switch, 18-11 
Establisher routine, 17-3 

examples of, 17-3 

introduction to, 17-1 
Evaluation rules 

discussion of, 5-12 

for blocks, 8-3 

for operator-expressions, 5-4 
%EXACTSTRING function, 15-22 
Exception handling, 17-1 
Executable-function*, 5-15 

SETUNWIND, 17-11 

SIGNAL, 17-5 

SIGNAL_STOP, 17-6 
EXECUTE 

psect-attribute, 18-3 
Execution of programs, 1-4 
Exit-expression*, 6-14 
%EXITITERATION function, 15-46 



Exitloop-expression*, 6-14 
%EXITMACRO function, 15-46 
EXPAND 

in module-switch, 19-5 

in switch, 18-11 
%EXPAND function, 15-42 
Expansion 

in lexical processing, 15-4 

of conditional-macro-call, 16-16 

of iterative-macro-call, 16-17 

of keyword-macro-call, 16-20 

of simple-macro-call, 16-15 
%EXPLODE function, 15-26 
Exponent*, 4-4 
Expression*, 4-1 

control -expression, 6-1 

in relation to field-references, 
11-19 

introduction to, 1-6 

operator-expression, 5-2 
EXTENDED 

in module-switch(36), 19-6 
Extension-attribute* 

as attribute, 9-3 

in general-structure-reference, 
11-35 

in structure-attribute, 11-24 
EXTERNAL 

in switch, 18-12 
External-declaration*, 10-6 
External-literal-declaration*, 14-4 
External-name*, 10-6 

introduction to, 1-15 
External-register-declaration*, 10-14 
External-routine-attribute*, 12-17 
External -routine-declaration* , 12-17 
Externals* 

in library source file, 10-7 



F10 linkage-type(36), 13-21, 13-26.1 
Fetch expression, 5-5 

introduction to, 1-5 
FFC(32), D-3 
FFS(32), D-3 

%FI in lexical-conditional, 15-49 
Field value 

definition of, 3-1, 3-4 

extension of, 3-4 
Field-attribute*, 9-5, 11-27 
Field-component*, 11-26 
Field-declaration*, 11-26 

examples of, 11-44, 17-22, 17-24 
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Field-definition*, 11-26 
Field-name* 

in data-declarations, 9-4 

in field-attribute, 9-5, 11-27 

in field-declaration, 11-26 

in general-structure-reference, 
11-35 

in ordinary-structure-reference, 
11-29 
Field-reference*, 11-12 

as primary, 4-18 

examples of, 11-18 

in assignment context, 11-15 

in fetch context, 11-15 

in other contexts, 11-16 

in relation to expressions, 11-19 

in structure-declarations, 11-18 

introduction to, 11-5 
Field-selector*, 11-12 

default, 11-19 

placement in structure-decl, 11-18 
Field-set-definition*, 11-26 
Field-set-name* 

in field-attribute, 9-5, 11-27 

in field-declaration, 11-26 
%FIELDEXPAND function, 15-34 
FIRSTONE(36), D-6 
Fixed-macro-body 

in iterative-macro-call, 16-17 
Float-literal*, 4-4 
Flow of control, 6-1 

introduction to, 1-10 
Formal-name* 

in ordinary-routine-decl, 12-9 
FORTRAN linkages, 13-27 
Forward-declaration*, 10-5 
Forward-routine-attribute*, 12-16 
Forward-routine-declaration*, 12-16 
Frame pointer (FP) register, 13-3 
Free character, 2-2 
FROM 

in case-expression, 6-5 

in loop-expression, 6-10 
Fullword 

definition of, 3-1 
Fullword values, 3-2 
Function (see 

Executable-function 

Lexical-function) 



%G in float-literal, 4-4 
GENERAL 
in addressing-mode-attribute, 9-17 



GENERAL (Cont.) 

in module-switch(32), 19-6 

in switch, 18-12 
General purpose structure, 11-52 
General register 

(see Register) 
General-structure-reference*, 11-35 

compared to ordinary-str-ref, 
11-37 

examples of, 11-29, 11-35, 11-37 
GEQ as infix operator, 5-8 
GEQA as infix operator, 5-8 
GEQU as infix operator, 5-8 
GLOBAL 

as psect storage-class, 18-3 

as psect-attribute, 18-3 

in data-declaration, 10-4 

in literal-declaration, 14-2 
GLOBAL linkage-option, 13-5, 13-8, 

13-10, 13-15, 13-22, 13-25 
Global register segments 

interaction with linkages, 13-31 
$GLOBAL$ default psect, 18-5 
Global-declaration*, 10-4 
Global-name*, 10-4 
Global-register-declaration*, 10-12 
Global-routine-attribute*, 12-15 
Global-routine-declaration*, 12-15 
GO TO construct, 6-1 
Govern 

declaration governs name, 
8-5 
Greater than 

in macro-call, 16-13 
GTR as infix operator, 5-8 
GTRA as infix operator, 5-8 
GTRU as infix operator, 5-8 

H 

%H in float-literal, 4-4 
HALT(16,32), D-2 
Handler routine, 17-6 
examples of, 17-8, 17-28 
introduction to, 17-1 
options of, 17-10 
Handler routine 
options of (Cont.) 
continuation, 17-10 
resignaling, 17-11 
unwinding, 17-11 
parameters, 17-8 
recursive, 17-18 
$HIG$ default psect, 18-5 



Index-7 



I 



IDENT 

in module-switch, 19-5 
%IDENTICAL function, 15-29 
Identifier 

(see Name or Keyword) 
%IF function, 15-49 
IF in conditional-expression, 6-2 
Imaginary block 

(see Implicit block) 
Immediately contains, 8-2 
Implicit block 

example of, 8-8 
Implicit declaration 

of formal name, 8-8 

of loop-index name, 8-8 
INCP(36), D-6 

INCR in loop-expression, 6-10 
INCRA in loop-expression, 6-10 
INCRU in loop-expression, 6-10 
INDEX(32), D-5 
Indexed-loop-expression*, 6-10 
INDIRECT 

in module-switch(36), 19-6 
Indirect recursion, 12-8 
Infix-operator, 5-3 
%INFORM function, 15-39 
Initial-attribute*, 9-8 
Initial-item* 

in initial-attribute, 9-8 
Input-actual-parameter* 

in routine-call, 12-3 
Input-formal-parameter 

in ordinary-routine-decl, 12-9 
INRANGE in case-expression, 6-5 
INSQHI(32), D-3 
INSQTI, D-3 
Integer- literal*, 4-3 
Internal-only 

character sequence, 15-15 

name, 15-16 
INTERRUPT linkage-type( 16,32), 13-10, 

13-12, 13-15 
IOT linkage-type(16), 13-10, 13-14 
%ISSTRING function, 15-30 
Iteration count 

in iterative-macro-call, 16-18 
Iterative flow, 6-1 
Iterative-macro-call, 16-13 

default punctuation, 16-18 

expansion of, 16-17 
Iterative- macro-definition*, 16-9 

examples of, 16-7 



JSB linkage(32) 

examples, 13-18 
JSB linkage-type(32), 13-15, 13-17 
JSR linkage-type(16), 13-10, 13-12 
JSYS linkage-type(36), 13-21 
JSYS(36), D-7 



K 



KA10 

in module-switch(36), 19-6 
Keyword 

complete list of, A-l 

in a declaration, 8-6 
Keyword -macro-call*, 16-13 

expansion of, 16-20 
Keyword -macro-declaration*, 16-9 

examples of, 16-7, 17-23, 17-25 
KI10 

in module-switch(36), 19-6 
KL10 

in module-switch(36), 19-6 
KS10 

in module-switch(36), 19-6 



Label*, 8-2 

in exit-expression, 6-14 
Label-declaration*, 18-17 
Labeled-block*, 8-2 
LANGUAGE 

in module-switch, 19-5 

in switch, 18-11 
checking performed for, C-l 
meaning of, 18-15 
Language-list* 

in module switch, 19-5 

in switch, 18-11 
LDB(36), D-6 
Leave-expression*, 6-14 
Left-operand, 5-3 
%LENGTH function, 15-46 

in conditional-macro expansion, 
16-16 

in iterative-macro expansion, 16-17 

in simple-macro expansion, 16-15 
LEQ as infix operator, 5-8 
LEQA as infix operator, 5-8 
LEQU as infix operator, 5-8 
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Less than 

in macro-call, 16-13 
Letter*, 4-16 
Lexeme, 2-3 

processing of, 15-2 
Lexical processing 

examples of, 15-5 

introduction to, 15-1 

of lexical-functions, 15-17 

of library source file, 16-29 

of macro calls, 16-14 

of numeric-literals, 15-13 

of string-literals, 15-14 
Lexical-alternative*, 15-49 
Lexical-conditional*, 15-49 
Lexical-consequence*, 15-49 
Lexical-expression*, 15-12 
Lexical-function 

^ALLOCATION, 15-33 

^ASSIGN, 15-36 

ScBLISS, 15-38 

( ;cCHAR, 15-23 

SrCHARCOUNT, 15-23 

%COUNT, 15-46 

%CTCE, 15-30 

f ; DECLARED, 15-37 

TERROR, 15-39 

%ERRORMACRO, 15-40 

%EXACTSTRING, 15-22 

%EXIT ITERATION, 15-46 

%EXITMACRO, 15-46 

%EXPAND, 15-42 

%EXPLODE, 15-26 

%FIELDEXPAND, 15-34 

%IDENTICAL, 15-29 

%IF, 15-49 

%INFORM, 15-39 

%ISSTRING, 15-30 

%LENGTH, 15-46 

%LTCE, 15-30 

%MESSAGE, 15-40 

%NAME, 15-27 

%NBITS, 15-32 

%NBITSU, 15-31 

%NULL, 15-29 

%NUMBER, 15-36 

%PRINT, 15-40 

%QUOTE, 15-41 

%QUOTENAME, 15-27 

%REMAINING, 15-45 

%REMOVE, 15-26 

%SBTTL, 15-41 

%SIZE, 15-33 

%STRING, 15-22 



Lexical-function (Cont.) 

summary of, 15-48 

< f SWITCHES, 15-38 

1 rTITLE, 15-40 
• ^UNQUOTE, 15-42 

f ( VARIANT, 15-38 

f VWARN, 15-39 
Lexical-function*, 15-18 

general rules for, 15-17 

quote-levels for, 15-20 
Lexical-function-name*, 15-18 
Lexical-test*, 15-49 
LIBRARY 

in module-switch, 19-5 

in switch, 18-11 
Library binary file, 16-28 
Library source file, 16-28 

declarations allowed in, 16-29 

lexical processing of, 16-29 
Library-declaration*, 16-28 
Linemark, 2-2 
Link-time-constant-expression* 

definition of, 7-5 

discussion of, 7-6 

introduction to, 1-16 

motivation for, 7-4 
LINKAGE 

in linkage-declaration, 13-5 

in module-switch, 19-5 

in switch, 18-11 
Linkage 

general definition of, 13-1 
Linkage-attribute*, 9-15 
Linkage-declaration* 

for BLISS-16, 13-10 

for BLISS-32, 13-15 

for BLISS-36, 13-21 

introduction to, 13-2 

typical syntax, 13-5 
Linkage-definition 

introduction to, 13-1 
Linkage-functions 

common, 13-28 

for BLISS-16 and -32, 13-31 
Linkage-name*, 13-5 

in switch, 18-11 

predeclared 
common, 13-27 
for BLISS-16, 13-14 
for BLISS-32, 13-20 
for BLISS-36, 13-26.2 
Linkage-option*, 13-5 

for BLISS-16, 13-10 

for BLISS-32, 13-15 
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Linkage-option*, (Cont.) 

for BLISS-36, 13-21 

introduction to, 13-8 
Linkage-type*, 13-5 

for BLISS- 16, 13-10 

for BLISS-32, 13-15 

for BLISS-36, 13-21 

introduction to, 13-6 
LINKAGE_REGS linkage-option, 13-22, 

13-25 
Linkages 

BLISS, 13-27 

FORTRAN-related, 13-27 

FORTRAN_FUNC, 13-28 

FORTRAN_SUB, 13-28 
Linker 

external names, 10-7 

handling of psects, 18-1 

role of, 1-4, 1-15 

use of IDENT switch, 19-11 

use of VERSION switch, 19-11 
LIST 

in module-switch, 19-5 

in switch, 18-11 
List-option*, 18-11 
Literal-attribute*, 14-2 
Literal-declaration*, 14-2 
LOCAL 

psect-attribute, 18-3 
Local-declaration*, 10-8 
LOCC(32), D-5 
Logical operations 

builtin(36), D-6 
LONG allocation-unit, 9-2 
LONG_RELATIVE 

in addressing-mode-attribute, 
9-17 

in module-switch(32), 19-6 

in switch, 18-12 
Longevity of data segment, 10-1 
Loop-expression*, 6-10 

introduction to, 1-11 
Loop-index* 

declaration of, 6-12 

implicit declaration of, 8-8 

loop-index*, 6-10 
$LOW$ default psect, 18-5 
LSH(36), D-6 
LSI11 

in module-switch(16), 19-5 
LSS as infix operator, 5-8 
LSSA as infix operator, 5-8 
LSSU as infix operator, 5-8 
%LTCE function, 15-30 



M 

Machine code insertion operations 

builtin(36), D-7 
Machine-specific function, 5-14 
MACHOP(36), D-7 
MACHSKIP(36), D-7 
Macro-call*, 16-13 

lexical processing of, 16-14 
Macro-declaration*, 16-8 

for BLOCK structure, 16-24 

introduction to, 16-6 

nested, 16-26 
Macro-formal-name*, 16-8 
Macro-quote level, 15-10 
MAIN 

in module-switch, 19-5 
Main routine, 1-3 
Mantissa*, 4-4 
Map-declaration*, 10-16 
MATCHC(32), D-5 
Matching 

of case-index, 6-6 

of select-index, 6-9 
MAX standard function, 5-16 
MAXA standard function, 5-16 
MAXU standard function, 5-16 
Mechanism vector, 17-9 
Memory management operations 

builtin(16), D-l 
%MESSAGE function, 15-40 
MFPD(16), D-l 
MFPI(16), D-l 
MFPR(32), D-2 
MFPS(16), D-l 
MIN standard function, 5-16 
MINA standard function, 5-16 
MINU standard function, 5-16 
Minus 

as infix operator, 5-7 

as prefix operator, 5-6 

in float-literal, 4-4 
Miscellaneous operations 

builtin(16,32), D-2, D-5 
MOD as infix operator, 5-7 
Mode* 

as switch, 18-12 

in addressing-mode-attribute, 9-17 
Module*, 19-2 

role of, 1-3 

small example of, 1-17 
Module-body*, 19-2 
Module-head*, 19-2 
Module-switch*, 19-4 
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MOVC3(32), D-5 
MOVC5(32), D-5 
MOVEPSL(32), D-3 
MOVP(32), D-5 
MOVTC(32), D-5 
MOVTUC(32), D-5 
MTPD(16), D-l 
MTPI(16), D-l 
MTPR(32), D-2 
MTPS(16), D-l 
MULD(16,32,36), D-2 
MULD(32), D-3 
MULF(16,32,36), D-2 
MULF(32), D-3 
MULG(32,36), D-3 
MULH(32), D-3 
Multiplication operator, 5-7 

N 

%NAME function, 15-27 

examples of, 16-25 
Name*, 4-16 

declaration of, 8-4 

internal-only, 15-16 

value of, 8-6 
Name-quote level, 15-10 
^rNBITS function, 15-32 
9rNBITSU function, 15-31 
NEQ as infix operator, 5-8 
NEQA as infix operator, 5-8 
NEQU as infix operator, 5-8 
Nested macro definition, 

16-26 
Nested signal, 17-13 

examples of, 17-17 
Newline character, 2-2 
NOASSEMBLY 

in module-switch, 19-5 

in switch, 18-11 
NOBINARY 

in module-switch, 19-5 

in switch, 18-11 
NOCODE 

in module-switch, 19-4 
NOCOMMENTARY 

in module-switch, 19-5 

in switch, 18-11 
NODEBUG 

in module-switch, 19-4 
NODEFAULT 

in psect-declaration, 18-3 
NOEIS 

in module-switch(16), 19-5 



NOERRS 

in module-switch, 19-4 

in switch, 18-11 
NOEXECUTE 

psect-attribute, 18-3 
NOEXPAND 

in module-switch, 19-5 

in switch, 18-11 
NOINDIRECT 

in module-switch(36), 19-6 
NOLIBRARY 

in module-switch, 19-5 

in switch, 18-11 
Non-contiguous structure, 11-48 
(Non-letters) 

' (see Apostrophe) 

* (see Asterisk) 

{ (see Brace) 

} (see Brace) 

[ (see Bracket) 

] (see Bracket) 

: (see Colon) 

, (see Comma) 

= (see Equals) 

> (see Greater than) 

< (see Less than) 

- (see Minus) 

( (see Parenthesis) 
) (see Parenthesis) 
% (see Percent) 

(see Period) 
+ (see Plus) 
; (see Semicolon) 
/ (see Slash) 

(see Up arrow) 
I (see Vertical bar) 
(Non- words) 
,... (see Syntax notation) 

— (see Syntax notation) 
... (see Syntax notation) 

NONEXTERNAL 

in switch, 18-12 
Nonprimitive lexical-expression, 15-12 
Nonprinting- character 

representation of, 4-8 
NOOBJECT 

in module-switch, 19-5 

in switch, 18-11 
NOOPTIMIZE 

in module-switch, 19-4 

in switch, 18-11 
NOP(16,32), D-2 
NOPIC 

psect-attribute, 18-3 
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NOPRESERVE linkage-option, 13-5, 13-8, 

13-10, 13-15, 13-22 
NOREAD 

psect-attribute, 18-3 
NOREQUIRE 

in module-switch, 19-5 

in switch, 18-11 
Normal-quote level, 15-10 
NOSAFE 

in module-switch, 19-4 

in switch, 18-11 
NOSHARE 

psect-attribute, 18-3 
NOSOURCE 

in module-switch, 19-5 

in switch, 18-11 
NOSYMBOLIC 

in module-switch, 19-5 

in switch, 18-11 
NOT as prefix operator, 5-9 
Notation for syntax, 2-5 
NOTRACE 

in module-switch, 19-5 

in switch, 18-11 
NOTUSED linkage-option, 13-15, 13-18 
NOUNAMES 

in module-switch, 19-4 

in switch, 18-11 
Novalue-attribute*, 9-14 

example of, 1-9, 9-13 
NOWRITE 

psect-attribute, 18-3 
NOZIP 

in module-switch, 19-4 

in switch, 18-11 
%NULL function, 15-29 
NULLPARAMETER linkage-function, 13-31 
%NUMBER function, 15-36 
Number-sign 

in lexical-function def., 15-20 
Numeric-literal*, 4-3 

lexical processing of, 15-13 



OF (Cont.) 

in plit, 4-13 

in select-expression, 6-8 
Offset 

as value of name, 8-6 

in alignment-attribute, 9-6 
On-off-switch*, 18-11, 19-4 
One-origin vector structure, 11-46 
Operand, 5-3 
Operator-expression*, 5-2 
Opt-sign*, 4-3 

Optimization, effects of, 1-14, 8-3 
OPTIMIZE 

in module-switch, 19-4 

in switch, 18-11 
OPTLEVEL 

in module-switch, 19-5 
OR as infix operator, 5-9 
Ordinary-routine-declaration*, 12-9 
Ordinary-structure-reference*, 11-29 

compared to general-str-ref, 11-37 

examples of, 11-28 
ORIGIN 

psect-attribute, 18-3 
OTHERWISE in select-expression, 6-8 
OTS 

in module-switch(36), 19-6 
OTS—LINKAGE 

in module-switch(36), 19-6 
Output-actual-parameter* 

in routine-call, 12-3 
Output-formal-parameter 

in ordinary-routine-decl, 12-9 
OUTRANGE in case-expression, 6-5 
OVERLAY 

psect-attribute, 18-3 
Overlay data, 10-1 
OWN 

in psect-declaration, 18-3 
$OWN$ default psect, 18-5 
Own-declaration*, 10-2 



%0 in integer-literal, 4-3 
OBJECT 

in module-switch, 19-5 

in switch, 18-11 
Object file, 1-15 
ODT 

in module-switch(16), 19-5 
OF 

in case-expression, 6-5 



%P in string-literal, 4-8 
Packed decimal string 
(see also 
(see also 
Decimal string literal 
Decimal string operations) 
%P 
Parameter 
enable-actual, 17-3 
of handler routine 
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Parameter 
of handler routine (Cont.) 
enable vector, 17-9 
mechanism vector, 17-9 
signal vector, 17-8 
(see also 
Actual-parameter 
Formal-name 
Lexical-actual-param 
Macro-actual-parameter 
Macro-formal-name) 
Parameter passing, 12-11 
methods of, 13-7 
by argument pointer, 13-7 
by register, 13-7 
implicit stack location, 13-7 
Parameter validation operations 

builtin(32), D-2 
Parameter-location*, 13-5, 13-10, 
13-15, 13-21 
discussion of, 13-7 
Parenthesis 

in macro-actual-parameter, 16-14 
Parenthesization 
default rules, 5-3 
discussion of, 5-11 
Parenthesized expression, 8-2 

introduction to, 1-8 
Partially overlayed structure, 11-50 
Percent 
before name, 5-15, 15-18 
in macro-declaration, 16-8, 16-9 
Performance measurement 

using condition handling, 17-29 
Period 
in fetch expression, 5-5 
in float-literal, 4-4 
Permanent data, 10-1 
PIC 
in module-switch(16), 19-5 
psect-attribute, 18-3 
PLIT 

in plit, 4-13 

in psect-declaration, 18-3 
$PLIT$ default psect, 18-5 
Plit*, 4-13 
Plit-item*, 4-13 
Plus 
as infix operator, 5-7 
as prefix operator, 5-6 
in float-literal, 4-4 
POINT(36), D-6 
Pointer functions 
for character handling, 20-5 



PORTAL linkage-option, 13-22, 13-25 
Position* in field-selector, 11-12 
Positional-macro-call*, 16-13 
Positional-macro-declaration*, 16-8 

examples of, 16-7 
Post-tested-loop*, 6-13 
Pre-tested-loop*, 6-13 
Precedence of operators, 5-2 
Predeclared name 

complete list of, A-l 

declaration of, 8-5 

for literal, 14-3 

for macro, 16-11 

for structure, 11-38 

summary of, 19-11 
Predefined identifiers, 19-11 

classification of, A-l 

complete list of, A-l 
Prefix sign expression, 5-6 
Prefix-operator, 5-3 
PRESERVE linkage-option, 13-5, 13-8, 

13-10, 13-15, 13-22 
Preset-attribute*, 9-10 
Preset-item* 

in preset-attribute, 9-10 
Preset-value* 

in preset-attribute, 9-10 
Primary*, 4-2 
Primitive lexical-expression, 

15-12 
%PRINT function, 15-40 
Printing-character, 4-8 
Priority levels, 5-2 

discussion of, 5-11 
PROBER(32), D-2 
PROBEW(32), D-2 
Procedures 

(see routines), 12-1 
Processor action operations 

builtin(16,32), D-2, D-5 
Processor register operations 

builtin(32), D-2 
Processor status operations 

builtin(16), D-l 
Program, 19-13 

development of, 1-3 

execution of, 1-4 

small example of, 1-16 
Program counter (PC) register, 

13-3 
Program stack, 3-16 
Program status operations 

builtin(32), D-3 
Program storage, 3-16 
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PS_INTERRUPT linkage-type(36), 13-21, 

13-26.1 
Psect-allocation attribute*, 9-11 
Psect-allocation* 

in plit, 4-13 
Psect-attribute*, 18-3, 18-7 
Psect-declaration*, 18-3 
Psect-name* 

in psect-allocation attribute, 9-11 

in psect-declaration, 18-3 
Punctuation mark, 2-3 
PUSHJ linkage-type(36), 13-21, 13-25 



Quantity of storage, 9-2 
Queue operations 

builtin(32), D-3 
Quotation, 15-8 

in macro-calls, 16-14 

in macros, 16-4 

levels of, 15-10 

lexical-functions for, 15-41 

rules for, 15-10 
r ;pQUOTE function, 15-41 

examples of, 16-4, 16-26 

in macro-actual-parameter, 16-14 
Quote-level, 15-10 

examples of, 15-42 

in lexical-functions, 15-20 
Quoted-string*, 4-8 
r rQUOTENAME function, 15-27 



R 



RAD50_10 

code table, B-6 

encoding, B-5 
%RAD50_10 in string-literal, 4-8 
RAD50__11 

code table, B-4 

encoding, B-3 
%RAD50_11 in string-literal, 4-8 
Radix-50 encoding, B-3 

(see also 
%RAD50_10 
%RAD50_11) 
Range-attribute*, 9-16 
READ 

psect-attribute, 18-3 
Reading characters, 20-7 
Record 

(see BLOCK structure), 11-38 



Record (Cont.) 

(see FIELD declaration), 11-38 
Recursive routine, 12-7 
Redeclaration 

by map-declaration, 8-8 
%REF 

(see also REF) 

standard function, 5-17 
REF 

(see also %REF) 

effect on structure-reference, 11-30 
introduction to, 11-7 

equivalent in general-str-ref, 11-37 

in structure-attribute, 11-24 
Register 

argument pointer (AP), 13-3, 13-7 

frame pointer (FP), 13-3 

program counter (PC), 13-3 

stack pointer (SP), 13-3 

value return, 13-3 
REGISTER parameter-location, 13-5, 
13-10, 13-12, 13-15, 13-18, 13-21 
Register usage categories, 13-3 
Register usage conventions, 13-8 

GLOBAL, 13-9 

NOPRESERVE, 13-9 

PRESERVE, 13-8 
Register-declaration*, 10-10 
Register-names 

builtin, 10-11 

standard, 10-11 
Registers, 3-17 

general purpose, 13-4 
globally usable, 13-4 
locally usable, 13-4 
non-preserved, 13-4 
not used, 13-4 
preserved, 13-4 

multi-purpose usage, 13-4 

passing parameters in, 13-4 

special purpose, 13-3 
Relational expression, 5-8 
RELATIVE 

in addressing-mode-attribute, 9-17 

in module-switch(16), 19-5 
RELATIVE (see 

LONG—RELATIVE 

WORD_RELATIVE) 
Relative address, 9-19 
%REMAINING function, 15-45 

examples of, 16-25 

in conditional-macro expansion, 16-17 

in iterative-macro expansion, 16-18 

in simple-macro expansion, 16-16 
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Remaining-actuals-list 

in iterative-macro-call, 16-17 
f V REMOVE function, 15-26 
REMQHK32), D-3 
REMQTI, D-3 
REP in plit, 4-13 
REPLACEK36), D-6 
REPLACEN(36), D-6 
Replication 

in syntax notation, 2-8 
Replicator*, 4-13 
REQUIRE 

in module-switch, 19-5 
in switch, 18-11 
Require-declaration*, 16-27 
Reserved word 

complete list of, A-l 
RESET(16), D-2 
Resignaling, 17-11 

examples of, 17-15 
Return character, 2-2 
Return-expression*, 6-16 
Returned-value* 

element of mechanism vector, 17-9 

of establisher routine, 17-9 
Right-operand, 5-3 
ROT(16,32,36), D-l 
Routine, 12-1 

establisher, 17-3 

handler, 17-6 

main routine, 1-3 

signaler, 17-1 

small example of, 1-17 
Routine-attribute* 

in external-routine-decl, 12-17 

in forward-routine-decl, 12-16 

in global-routine-decl, 12-15 

in ordinary-routine-decl, 12-9 
Routine-body* 

in global-routine-declaration, 12-15 

in ordinary-routine-decl, 12-9 
Routine-call*, 12-3 
Routine-declaration*, 12-7 

implicit block, 8-8 
Routine-designator*, 12-3 
Routine-name* 

in enable-declaration, 17-3 

in external-routine-decl, 12-17 

in forward-routine-decl, 12-16 

in global-routine-declaration, 12-15 

in ordinary-routine-decl, 12-9 
RSX_AST linkage-type(16), 13-10, 13-12, 

13-14 
RTT linkage-option, 13-10, 13-13 



SAFE 

in module-switch, 19-4 

in switch, 18-11 
Satisfaction of test, 6-2 
%SBTTL function, 15-41 
Scalar data segment, 3-6 

allocation of, 3-7 
SCANC(32), D-5 
SCANI(36), D-6 
SCANN(36), D-6 
Scope of declaration, 8-5 

examples of, 8-4, 8-6 
Searching character sequences, 20-14 
Segment-name* 

in ordinary-structure-reference, 
11-29 
SELECT in select-expression, 6-8 
Select-expression*, 6-8 
Select-label* 

in select-expression, 6-8 
Select-line* 

in select-expression, 6-8 
SELECTA in select-expression, 6-8 
SELECTONE in select-expression, 6-8 
SELECTONEA in select-expression, 6-8 
SELECTONEU in select-expression, 6-8 
SELECTU in select-expression, 6-8 
Semicolon 

in block, 8-2 

in general-structure-reference, 11-35 

in structure-declaration, 11-22 

significance of, 8-3 
Separation rules, 2-4 

for numeric-literal, 4-4 
Sequence-comparing functions, 20-12 
Sequence-searching functions, 20-14 
Sequence-translating functions, 20-15 
Sequence-writing functions, 20-9 
Sequential flow, 6-1 
SET 

in case-expression, 6-5 

in field-declaration, 11-26 

in select-expression, 6-8 
SETUNWIND function, 17-11 
SHARE 

psect-attribute, 18-3 
Shift operator, 5-6 
Side effects, 4-17 
SIGN function, 5-15 
Sign-extension-flag*, 11-12 
Signal, 17-2 

implicit, 17-6 
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Signal, (Cont.) 

nested, 17-13 

unwind, 17-6 
SIGNAL function, 17-5 

assigning value of, 17-9 
Signal vector, 17-8 
SIGNAL—STOP function, 17-6 
Signaler routine, 17-1 
SIGNED 

in extension-attribute, 9-3 

in range-attribute, 9-16 
Signed value extension, 3-4 
Simple-macro-call, 16-13 

expansion of, 16-15 
Simple-macro-definition*, 16-8 

examples of, 16-7 
SIXBIT 

literal (see %SIXBIT) 

code table, B-8 

encoding, B-8 
%SIXBIT in string-literal, 4-8 
%SIZE function, 15-33 
Size* in field-selector, 11-12 
SKIP linkage-option, 13-22 
SKPC(32), D-5 
Slash as operator, 5-7 
SOURCE 

in module-switch, 19-5 

in switch, 18-11 
Source file, 1-15 
Source listing counter, 18-15 
Space, 2-3 
SPANC(32), D-5 
Special character, 2-2 
Special-switch*, 18-11, 18-14, 19-5 
SPL(16), D-l 
STACK 

in module-switch(36), 19-6 
Stack, 3-16 
Stack frame, 13-3 
STACK parameter-location, 13-10 
Stack pointer (SP) register, 13-3 
Stackframe for LOCAL data, 10-8 
Stacklocal-declaration*, 10-9 
STANDARD parameter-location, 13-5, 

13-15, 13-21 
Standard-function, 5-14 
Statement 

block-action as, 8-3 
Storage, 3-16 
Storage allocation 

using structure-attribute, 11-25 
Storage-class* 

in psect-declaration, 18-3 



String encodings, B-l 

ASCII, B-l 

RAD50_10, B-5 

RAD50__11, B-3 

Radix-50, B-3 

SIXBIT, B-8 
%STRING function, 15-22 
String operations 

compile-time 
(see Lexical Functions), 15-1 

run-time 
(see Character Handling), 20-1 
String-literal*, 4-8 

lexical processing of, 15-14 
String-type*, 4-8 
STRUCTURE 

in module-switch, 19-5 

in switch, 18-11 
Structure, 3-6 

(see also Data structures) 

introduction to, 1-10 

predeclared 
BITVECTOR, 3-10, 11-38 
BLOCK, 3-10, 11-38 
BLOCKVECTOR, 3-11, 11-38 
VECTOR, 3-8, 11-38 

user-defined, 3-12, 11-46, 11-47, 
11-48, 11-50, 11-52 
Structure allocation, 11-23 

introduction to, 11-7 
Structure-attribute*, 11-24 

in switch, 18-11, 19-5 
Structure-body*, 11-22 
Structure-declaration*, 11-22 

interchangable, 11-8 

introduction to, 11-6 

placement of field -selector, 11-18 
Structure-name* 

in general-structure-reference, 
11-35 

in structure-attribute, 11-24 

in structure-declaration, 11-22 
Structure-reference*, 11-29 

as primary, 4-17 

examples of, 11-28 

introduction to, 11-7 
Structure-size*, 11-22 
SUBD(16,32,36), D-2 
SUBF(16,32,36), D-2 
SUBG(32,36), D-4 
SUBH(32), D-4 
SUBM(16,32), D-2 
Subroutine flow, 6-1 
Subtraction operator, 5-8 
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Supplementary functions, 5-14 

for character handling, 20-1 
SWAB(16), D-l 
c < SWITCHES function, 15-38 
Switches-declaration*, 18-11 

in library source file, 16-29 
SYMBOLIC 

in module-switch, 19-5 

in switch, 18-11 
Symbolic constants 

(see BIND-data-declaration, 
LITERAL declaration), 14-1 
Symmetric array structure, 11-47 
Syntax notation, 2-5 

concatenation, 2-6 

dialect-specific features, 2-8 

disjunction, 2-7 

ellipsis, 2-7 

replication, 2-8 

syntactic literal, 2-6 

syntactic name, 2-6 

syntactic rule, 2-5 
System interface operations 

builtin(36), D-7 



Til 

in module-switch(16), 19-5 
Tab character, 4-8 
Target systems, 1-1 
Target-system differences, 3-6 
Temporary data, 10-1 
TES 

in case-expression, 6-5 

in field-declaration, 11-26 

in select-expression, 6-8 
Test*, 6-2 

incomplete evaluation of, 6-4 
TESTBITCC(32), D-3 
TESTBITCCK32), D-3 
TESTBITCS(32), D-3 
TESTBITSC(32), D-3 
TESTBITSS(32), D-3 
TESTBITSSK32), D-3 
Tested-loop-expression*, 6-13 
THEN in conditional-expression, 6-2 
%THEN in lexical-conditional, 

15-49 
%TITLE function, 15-40 
TO 

in case-expression, 6-5 

in loop -expression, 6-10 

in select-expression, 6-8 



TOPS10 

in module-switch(36), 19-6 
TOPS20 

in module-switch(36), 19-6 
TRACE 

in module-switch, 19-5 

in switch, 18-11 
Trailing comment, 2-4 
Transfer vector, 6-7 
Transportability checking, 18-15, 

C-l 
TRAP linkage-type(16), 13-10, 13-14 
Two-dimensional structure, 11-47 



u 



UNAMES 
in module-switch, 19-4 
in switch, 18-11 
Unary operators, 5-2 
Uncounted plit, 4-12 
Undeclare-declaration*, 18-18 
Undefined value of block, 8-3 
^UNQUOTE function, 15-42 

examples of, 15-9, 15-43, 16-27 
UNSIGNED 
in extension-attribute, 9-3 
in range-attribute, 9-16 
Unsigned value extension, 3-4 
UNTIL in loop-expression, 6-13 
Unwind signal, 17-6 
Unwinding, 17-11 

examples of, 17-17 
Up-arrow operator, 5-6 
UPLIT in plit, 4-13 
%UPVAL literal-name, 14-3 
User-defined structures, 11-46 
bounds-checking structure, 11-46 
general purpose structure, 11-52 
non-contiguous structure, 11-48 
one-origin vector structure, 11-46 
partially overlayed structure, 11-50 
symmetric array structure, 11-47 
two-dimensional structure, 11-47 
UUO(36), D-7 



Value 
discarded value, 6-4 
extension of, 9-3 
of a block, 8-3 
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Value (Cont.) 

of names, 8-6 

undefined value, 8-3 
Value return register, 13-3 
VALUECBIT linkage-option, 13-10, 13-13 
Values 

normal representation of, 3-1 
%VARIANT function, 15-38 
/VARIANT in compiler command, 15-38 
VAX-11 calling standard, 13-16 
VAX/VMS 

condition handling in, 17-29 
VECTOR 

as psect-attribute, 18-3, 18-8 
VECTOR structure, 11-38 

example of, 3-8 
VERSION 

in module-switch, 19-5 
Vertical bar in syntax, 2-7 
Volatile-attribute*, 9-13 

use in condition handling, 17-4, 
17-8, 17-29 



Weak-attribute*, 9-19 

in external-routine-decl, 12-17 

purpose of, 10-7 
WHILE in loop-expression, 6-13 
WITH in leave-expression, 6-14 
WORD allocation-unit, 9-2 
WORD_RELATIVE 

in addressing-mode-attribute, 
9-17 

in module-switch(32), 19-6 

in switch, 18-12 
WRITE 

psect-attribute, 18-3 
Writing character sequences, 20-9 
Writing characters, 20-8 



%X in integer-literal, 4-3 

XFC(32), D-5 

XOR as infix operator, 5-9 



w 

WAIT(16), D-2 
%WARN function, 15-39 



ZIP 

in module-switch, 19-4 
in switch, 18-11 
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